Beberapa kata dari biro penerjemahan kami: biasanya setiap orang berupaya menerjemahkan materi dan publikasi terbaru, dan kami tidak terkecuali. Tapi terminal bukanlah sesuatu yang diperbarui seminggu sekali. Oleh karena itu, kami telah menerjemahkan untuk Anda sebuah artikel oleh Antoine Beaupré, yang diterbitkan pada musim semi tahun 2018: meskipun “usianya” cukup besar menurut standar modern, menurut pendapat kami, materi tersebut tidak kehilangan relevansinya sama sekali. Selain itu, ini awalnya merupakan rangkaian dua artikel, namun kami memutuskan untuk menggabungkannya menjadi satu postingan besar.
Terminal memiliki tempat khusus dalam sejarah komputer, namun dalam beberapa dekade terakhir terminal terpaksa bertahan seiring dengan keberadaan baris perintah karena antarmuka grafis sudah ada di mana-mana. menggantikan milik mereka sendiri , yang, pada gilirannya, merupakan modifikasi sistem berdasarkan kartu berlubang dan sakelar sakelar. Distribusi modern hadir dengan beragam emulator terminal dalam segala bentuk dan warna. Dan meskipun banyak yang puas dengan terminal standar yang disediakan oleh lingkungan kerja mereka, beberapa dengan bangga menggunakan perangkat lunak yang benar-benar eksotis untuk menjalankan shell atau editor teks favorit mereka. Namun, seperti yang akan kita lihat dari artikel ini, tidak semua terminal dibuat dengan gambar yang sama: terminal tersebut sangat berbeda dalam fungsi, ukuran, dan kinerja.
Beberapa terminal memiliki celah keamanan yang sangat mengejutkan, ditambah lagi sebagian besar memiliki serangkaian fungsi yang sangat berbeda, mulai dari dukungan untuk antarmuka bertab hingga skrip. Meskipun kita , artikel ini merupakan pembaruan dari materi sebelumnya yang akan membantu pembaca menentukan terminal mana yang akan digunakan di tahun 2018. Paruh pertama artikel membandingkan fitur, dan paruh kedua mengevaluasi kinerja.
Berikut terminal yang saya ulas:
Ini mungkin bukan versi terbaru, karena saya terbatas pada versi stabil pada saat penulisan, yang dapat saya luncurkan di Debian 9 atau Fedora 27. Satu-satunya pengecualian adalah Alacritty. Ini adalah turunan dari terminal berakselerasi GPU dan ditulis dalam bahasa yang tidak biasa dan baru untuk tugas ini - Rust. Saya mengecualikan terminal web dari ulasan saya (termasuk yang ada di ), karena tes pendahuluan menunjukkan kinerjanya sangat buruk.
Dukungan Unicode
Saya memulai pengujian saya dengan dukungan Unicode. Tes pertama terminal adalah menampilkan string Unicode dari : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 dan 말.” Tes sederhana ini menunjukkan apakah terminal dapat beroperasi dengan benar di seluruh dunia. terminal xterm tidak menampilkan karakter Arab dalam konfigurasi default:
Secara default, xterm menggunakan font klasik "tetap", yang menurutnya , memiliki "cakupan Unicode yang substansial sejak 1997". Ada sesuatu yang terjadi pada font ini yang menyebabkan karakter muncul sebagai bingkai kosong dan hanya ketika font teks ditingkatkan menjadi 20+ poin barulah karakter tersebut akhirnya mulai ditampilkan dengan benar. Namun, “perbaikan” ini 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 menangani font dengan benar. Untungnya ini telah diperbaiki di versi yang lebih baru.
Sekarang perhatikan bagaimana garis tersebut ditampilkan di xterm. Ternyata lambang Mem dan Semit berikut ini lihat skrip gaya RTL (), jadi secara teknis harus ditampilkan dari kanan ke kiri. Browser web seperti Firefox 57 menangani baris di atas dengan benar. Versi teks RTL yang lebih sederhana adalah kata "" dalam bahasa Ibrani (). mengatakan sebagai berikut:
“Banyak program komputer tidak dapat menampilkan teks dua arah dengan benar. Misalnya, nama Ibrani "Sarah" terdiri dari karakter sin (ש) (yang muncul di sebelah kanan), lalu resh (ר) dan terakhir he (ה) (yang muncul di sebelah kiri)."
Banyak terminal yang gagal dalam pengujian ini: Alacritty, terminal Gnome dan XFCE yang diturunkan dari VTE, urxvt, st dan xterm menampilkan "Sara" dalam urutan terbalik, seolah-olah kita telah menulis nama sebagai "Aras".
Masalah lain dengan teks dua arah adalah teks tersebut harus diselaraskan, terutama saat mencampurkan teks RTL dan LTR. Skrip RTL harus dijalankan dari sisi kanan jendela terminal, tetapi apa yang akan terjadi pada terminal yang menggunakan LTR Bahasa Inggris secara default? Kebanyakan dari mereka tidak memiliki mekanisme khusus dan meratakan semua teks ke kiri (termasuk di Konsole). Pengecualiannya adalah pterm dan mlterm, yang mematuhi standar dan meluruskan garis tersebut.
Perlindungan penyisipan
Fitur penting berikutnya yang saya identifikasi adalah perlindungan anti-penyisipan. Meskipun diketahui secara luas bahwa mantra seperti:
$ curl http://example.com/ | shadalah perintah push eksekusi kode, hanya sedikit orang yang tahu bahwa perintah tersembunyi dapat menyelinap ke konsol saat menyalin dan menempel dari browser web, bahkan setelah pemeriksaan yang cermat. dengan cemerlang menunjukkan betapa tidak berbahayanya perintah tersebut:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitberubah menjadi gangguan ketika ditempelkan 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.gitBagaimana itu bekerja? Kode berbahaya disertakan dalam blok , yang dipindahkan dari tampilan pengguna menggunakan CSS.
jelas dirancang untuk menetralisir serangan semacam itu. Dalam mode ini, terminal menyertakan teks yang ditempelkan dalam sepasang rangkaian escape khusus untuk memberi tahu shell tentang asal teks. Ini memberi tahu shell bahwa ia dapat mengabaikan karakter khusus yang mungkin terdapat dalam teks yang ditempelkan. Semua terminal yang kembali ke xterm yang terhormat mendukung fitur ini, tetapi menempelkan dalam mode Bracketed memerlukan dukungan dari shell atau aplikasi yang berjalan di terminal. Misalnya saja penggunaan perangkat lunak (Bash yang sama), membutuhkan file ~/.inputrc:
set enable-bracketed-paste onSayangnya, situs pengujian Horn juga menunjukkan cara melewati perlindungan ini melalui pemformatan teks itu sendiri dan akhirnya menerapkan mode Bracketed sebelum waktunya. Ini berfungsi karena beberapa terminal tidak memfilter urutan escape dengan benar sebelum menambahkan urutannya sendiri. Misalnya, di milik saya, saya tidak pernah berhasil menyelesaikan pengujian Konsole bahkan dengan konfigurasi yang benar .inputrc mengajukan. Ini berarti konfigurasi sistem Anda dapat dengan mudah rusak karena aplikasi yang tidak didukung atau shell yang tidak dikonfigurasi dengan benar. Hal ini sangat berbahaya ketika masuk ke server jarak jauh, di mana pekerjaan konfigurasi yang hati-hati kurang umum dilakukan, terutama jika Anda memiliki banyak mesin jarak jauh seperti itu.
Solusi yang baik untuk masalah ini adalah tempelkan plugin konfirmasi untuk terminal urxvt, yang hanya meminta izin untuk menyisipkan teks apa pun yang berisi baris baru. Saya belum menemukan opsi yang lebih aman untuk serangan teks yang dijelaskan oleh Horn.
Tab dan profil
Fitur yang populer saat ini adalah dukungan untuk antarmuka bertab, yang akan kita definisikan sebagai satu jendela terminal yang berisi beberapa terminal lainnya. Fungsi ini berbeda untuk terminal yang berbeda, dan meskipun terminal xterm tradisional tidak mendukung tab sama sekali, inkarnasi terminal yang lebih modern seperti Terminal Xfce, Terminal GNOME, dan Konsole memiliki fungsi ini. Urxvt juga mendukung tab, tetapi hanya jika Anda menggunakan plugin. Namun dalam hal dukungan tab itu sendiri, Terminator adalah pemimpin yang tak terbantahkan: 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 mengirimkan penekanan tombol yang sama ke beberapa terminal pada saat yang sama, menyediakan alat sederhana untuk melakukan operasi massal di beberapa server secara bersamaan. Fitur serupa juga diterapkan di Konsole. Untuk menggunakan fitur ini di terminal lain, Anda harus menggunakan perangkat lunak pihak ketiga seperti , или .
Tab berfungsi dengan baik terutama bila dipasangkan dengan profil: misalnya, Anda dapat memiliki satu tab untuk email, tab lainnya untuk obrolan, dan seterusnya. Ini didukung dengan baik oleh Terminal Konsole dan Terminal GNOME. Keduanya memungkinkan setiap tab meluncurkan profilnya sendiri secara otomatis. Terminator juga mendukung profil, tetapi saya tidak dapat menemukan cara untuk meluncurkan program tertentu secara otomatis saat Anda membuka tab tertentu. Terminal lain tidak memiliki konsep “profil” sama sekali.
kerutan
Hal terakhir yang akan saya bahas di bagian pertama artikel ini adalah tampilan terminalnya. Misalnya GNOME, Xfce dan urxvt mendukung transparansi, namun baru-baru ini menghentikan dukungan untuk gambar latar belakang, sehingga memaksa beberapa pengguna untuk beralih ke terminal . Secara pribadi, saya senang dengan itu dan itu sederhana sumber daya x, yang menetapkan kumpulan warna latar belakang dasar untuk urxvt. Namun, tema warna yang tidak standar juga dapat menimbulkan masalah. Misalnya, dengan aplikasi и , karena mereka sudah menggunakan warnanya sendiri.
tidak mendukung warna, dan warna baru seringkali terbatas pada palet 256 warna. Untuk pengguna tingkat lanjut yang menata terminalnya, perintah shell atau bilah status dengan cara yang rumit dapat menjadi batasan yang mengganggu. melacak terminal mana yang memiliki dukungan "True Color". Pengujian saya mengonfirmasi bahwa terminal berbasis st, Alacritty, dan VTE mendukung True Color dengan sempurna. Terminal lain tidak memberikan hasil yang baik dalam hal ini dan, pada kenyataannya, bahkan tidak menampilkan 256 warna. Di bawah ini Anda dapat melihat perbedaan antara dukungan True Color di terminal GNOME, st dan xterm, yang berfungsi dengan baik dengan 256 palet warnanya, dan urxvt, yang tidak hanya gagal dalam pengujian, tetapi bahkan menampilkan beberapa karakter yang berkedip.
Beberapa terminal juga menganalisis teks untuk mencari pola URL agar tautan dapat diklik. Ini berlaku untuk semua terminal turunan VTE, sementara urxvt memerlukan plugin khusus yang akan mengubah URL dengan sekali klik atau menggunakan pintasan keyboard. Terminal lain Saya telah menguji URL tayangan dengan cara lain.
Terakhir, tren baru di terminal adalah opsionalitas buffer gulir. Misalnya, st tidak memiliki buffer gulir; diasumsikan bahwa pengguna akan menggunakan terminal multiplexer seperti tmux dan .
Alacritty juga tidak memiliki buffer backscroll, tapi dukungannya karena “umpan balik yang luas” tentang topik ini dari pengguna. Terlepas dari para pemula ini, setiap terminal yang saya uji yang saya temukan mendukung pengguliran terbalik.
Subtotal
Pada materi bagian kedua (dalam bahasa aslinya ini adalah dua artikel berbeda - kira-kira. jalur) kami akan membandingkan kinerja, penggunaan memori, dan latensi. Namun kita sudah dapat melihat bahwa beberapa terminal tersebut memiliki kekurangan yang serius. Misalnya, pengguna yang rutin bekerja dengan skrip RTL mungkin ingin mempertimbangkan mlterm dan pterm, karena mereka lebih baik dalam menangani tugas serupa dibandingkan yang lain. Konsole juga berkinerja baik. Pengguna yang tidak bekerja dengan skrip RTL dapat memilih yang lain.
Dalam hal perlindungan terhadap penyisipan kode berbahaya, urxvt menonjol karena penerapan perlindungan khusus terhadap jenis serangan ini, yang tampaknya nyaman bagi saya. Bagi mereka yang mencari fitur menarik, Konsole layak untuk dilihat. Terakhir, perlu dicatat bahwa VTE adalah basis terminal yang sangat baik, yang menjamin dukungan warna, pengenalan URL, dan sebagainya. Pada pandangan pertama, terminal default yang disertakan dengan lingkungan favorit Anda mungkin memenuhi semua persyaratan, tetapi biarkan pertanyaan ini terbuka sampai kami memahami kinerjanya.
Kami melanjutkan percakapan
Secara umum, kinerja terminal itu sendiri mungkin tampak seperti masalah yang tidak masuk akal, namun ternyata, beberapa di antaranya menunjukkan latensi yang sangat tinggi untuk perangkat lunak dengan tipe fundamental seperti itu. Selanjutnya kita juga akan melihat apa yang secara tradisional disebut "kecepatan" (sebenarnya, ini adalah kecepatan pengguliran) dan konsumsi memori terminal (dengan peringatan bahwa saat ini hal ini tidak sepenting beberapa dekade yang lalu).
Keterlambatan
Setelah mempelajari kinerja terminal secara menyeluruh, saya sampai pada kesimpulan bahwa parameter terpenting dalam hal ini adalah latensi (ping). Dalam artikelnya Pavel Fatin melihat latensi berbagai editor teks dan mengisyaratkan bahwa terminal dalam hal ini mungkin lebih lambat daripada editor teks tercepat. Petunjuk inilah yang pada akhirnya mengarahkan saya untuk menjalankan pengujian saya sendiri dan menulis artikel ini.
Namun apa itu latensi dan mengapa latensi begitu penting? Dalam artikelnya, Fatin mendefinisikannya sebagai “penundaan antara menekan tombol dan pembaruan layar terkait” dan mengutipnya , yang menyatakan: “Keterlambatan umpan balik visual pada layar komputer mempunyai dampak penting terhadap perilaku dan kepuasan juru ketik.”
Fatin menjelaskan bahwa ping ini memiliki konsekuensi yang lebih dalam dari sekadar kepuasan: “mengetik menjadi lebih lambat, lebih banyak kesalahan terjadi, dan ketegangan mata serta otot meningkat.” Dengan kata lain, penundaan yang besar dapat menyebabkan kesalahan ketik dan juga menurunkan kualitas kode, karena menyebabkan beban kognitif tambahan pada otak. Namun yang lebih buruk adalah ping "meningkatkan ketegangan mata dan otot", yang sepertinya menyiratkan hal tersebut di masa depan (Rupanya, yang penulis maksud adalah masalah pada otot mata, punggung, lengan dan, tentu saja, penglihatan - kira-kira. jalur) karena stres yang berulang.
Beberapa dampak tersebut sudah diketahui sejak lama dan hasilnya , yang diterbitkan pada tahun 1976 di jurnal Ergonomics, mengatakan bahwa penundaan 100 milidetik "secara signifikan mengganggu kecepatan mengetik". Baru-baru ini, Panduan Pengguna GNOME diperkenalkan dalam 10 milidetik, dan jika Anda melangkah lebih jauh, maka menunjukkan bahwa 1 milidetik adalah waktu ideal.
Fatin melakukan pengujian pada editor teks; dia menciptakan instrumen portabel yang disebut , yang saya gunakan untuk menguji ping di emulator terminal. Ingatlah bahwa pengujian dilakukan dalam mode simulasi: pada kenyataannya, kita perlu memperhitungkan latensi input (keyboard, pengontrol USB, dll.) dan output (buffer kartu video, monitor). Menurut Fatin, pada konfigurasi tipikal, kecepatannya sekitar 20 ms. Jika Anda memiliki peralatan gaming, Anda dapat mencapai angka ini hanya dalam 3 milidetik. Karena kami sudah memiliki perangkat keras yang begitu cepat, aplikasi tidak perlu menambahkan latensinya sendiri. Tujuan Fatin adalah menjadikan latensi aplikasi menjadi 1 milidetik, atau bahkan mencapai panggilan tanpa panggilan , bagaimana .
Berikut hasil pengukuran saya, serta beberapa hasil Fatin, untuk menunjukkan bahwa eksperimen saya sesuai dengan pengujiannya:
Hal pertama yang mengejutkan saya adalah waktu respons yang lebih baik dari program lama seperti xterm dan mlterm. Dengan latensi register terburuk (2,4 ms), kinerjanya lebih baik daripada terminal modern tercepat (10,6 ms untuk st). Tidak ada terminal modern yang berada di bawah ambang batas 10 milidetik. Secara khusus, Alacritty gagal memenuhi klaim "emulator terminal tercepat yang tersedia", meskipun skornya telah meningkat sejak tinjauan pertama pada tahun 2017. Memang, penulis proyek tersebut dan berupaya meningkatkan tampilan. Perlu juga dicatat bahwa Vim yang menggunakan GTK3 jauh lebih lambat dibandingkan versi GTK2-nya. Dari sini kita dapat menyimpulkan bahwa GTK3 menciptakan latensi tambahan, dan ini tercermin di semua terminal lain yang menggunakannya (Terminator, Terminal Xfce4, dan Terminal GNOME).
Namun perbedaannya mungkin tidak terlihat secara kasat mata. Seperti yang dijelaskan Fatin, “Anda tidak perlu menyadari penundaan tersebut agar hal tersebut berdampak pada Anda.” Fatin juga memperingatkan tentang deviasi standar: “setiap gangguan dalam latensi (jitter) menciptakan tekanan tambahan karena ketidakpastiannya.”
Grafik di atas diambil pada Debian 9 murni (peregangan) dengan . Lingkungan ini memberikan hasil terbaik dalam pengujian latensi. Ternyata, GNOME membuat ping tambahan sebesar 20 ms untuk semua pengukuran. Penjelasan yang mungkin untuk hal ini adalah adanya program dengan pemrosesan kejadian masukan yang sinkron. Fatin mencontohkan kasus seperti itu , yang menambahkan penundaan dengan memproses semua peristiwa masukan secara sinkron. Secara default, GNOME juga dilengkapi dengan window manager , yang menciptakan lapisan buffering tambahan, yang memengaruhi ping dan menambahkan latensi minimal 8 milidetik.
Kecepatan gulir
Tes berikutnya adalah tes "kecepatan" atau "bandwidth" tradisional, yang mengukur seberapa cepat terminal dapat menggulir halaman sambil menampilkan teks dalam jumlah besar di layar. Mekanisme tesnya bervariasi; tes aslinya adalah dengan menghasilkan string teks yang sama menggunakan perintah seq. Tes lainnya termasuk tes Thomas E. Dickey (pengelola xterm), yang berulang kali . Dalam ulasan lain tentang kinerja terminal menggunakan string byte acak yang dikodekan base32, yang dikeluarkan ke terminal menggunakan cat. Luu menganggap pengujian semacam itu sebagai "tolok ukur yang tidak berguna seperti yang dapat dibayangkan" dan menyarankan penggunaan respons terminal sebagai metrik utama. Dickey juga menyebut tesnya menyesatkan. Namun, kedua penulis mengakui bahwa bandwidth jendela terminal dapat menjadi masalah. Luu menemukan Emacs Eshell membeku saat menampilkan file besar, dan Dickey mengoptimalkan terminal untuk menghilangkan kelesuan visual xtremm. Jadi pengujian ini masih ada manfaatnya, tetapi karena proses renderingnya sangat berbeda dari satu terminal ke terminal lainnya, pengujian ini juga dapat digunakan sebagai komponen pengujian untuk menguji parameter lainnya.
Di sini kita melihat rxvt dan st unggul dalam persaingan, diikuti oleh Alacritty yang jauh lebih baru, yang dirancang dengan fokus pada kinerja. Berikutnya adalah Xfce (keluarga VTE) dan Konsole yang hampir dua kali lebih cepat. Terakhir adalah xterm, yang lima kali lebih lambat dari rxvt. Selama pengujian, xterm juga banyak menimbulkan riak, membuat teks yang lewat sulit dilihat meskipun barisnya sama. Konsole cepat, tetapi terkadang rumit: tampilan akan terhenti dari waktu ke waktu, menampilkan sebagian teks atau tidak menampilkannya sama sekali. Terminal lain menampilkan string dengan jelas, termasuk st, Alacritty, dan rxvt.
Dickey menjelaskan perbedaan kinerja tersebut disebabkan oleh desain scroll buffer di terminal yang berbeda. Secara khusus, ia menuduh rxvt dan terminal lain "tidak mengikuti aturan umum":
“Tidak seperti xterm, rxvt tidak mencoba menampilkan semua pembaruan. Jika tertinggal, ia akan menolak beberapa pembaruan untuk mengejar ketinggalan. Hal ini berdampak lebih besar pada kecepatan pengguliran dibandingkan pada organisasi memori internal. Salah satu kelemahannya adalah animasi ASCII agak tidak tepat."
Untuk memperbaiki kelesuan xterm yang dirasakan ini, Dickey menyarankan untuk menggunakan sumber daya , memungkinkan xterm membuang beberapa pembaruan layar untuk mengikuti arus. Pengujian saya mengonfirmasi bahwa fastScroll meningkatkan kinerja dan menjadikan xterm setara dengan rxvt. Namun, ini adalah hal yang sulit, seperti yang dijelaskan Dickey sendiri: "terkadang xterm - seperti konsole - tampaknya terhenti saat menunggu serangkaian pembaruan layar baru setelah beberapa di antaranya dihapus." Dalam hal ini, tampaknya terminal lain telah menemukan kompromi terbaik antara kecepatan dan integritas tampilan.
Konsumsi sumber daya
Terlepas dari apakah masuk akal untuk mempertimbangkan kecepatan gulir sebagai metrik kinerja, pengujian ini memungkinkan kami untuk mensimulasikan beban pada terminal, yang pada gilirannya memungkinkan kami mengukur parameter lain seperti penggunaan memori atau disk. Metrik diperoleh dengan menjalankan pengujian yang ditentukan seq di bawah pemantauan proses Python. Dia mengumpulkan data meteran untuk ru_maxrss, jumlah ru_oublock и ru_inblock dan pengatur waktu sederhana.
Dalam pengujian ini, ST menempati posisi pertama dengan konsumsi memori rata-rata terendah sebesar 8 MB, hal ini tidak mengherankan mengingat ide utama desainnya adalah kesederhanaan. mlterm, xterm dan rxvt mengkonsumsi lebih banyak - sekitar 12 MB. Hasil penting lainnya adalah Alacritty, yang memerlukan 30 MB untuk dijalankan. Lalu ada terminal keluarga VTE dengan angka 40 hingga 60 MB, yang cukup banyak. Konsumsi ini dapat dijelaskan oleh fakta bahwa terminal ini menggunakan perpustakaan tingkat yang lebih tinggi, misalnya GTK. Konsole berada di urutan terakhir dengan konsumsi memori sebesar 65MB selama pengujian, meskipun hal ini dapat dibenarkan karena beragam fiturnya.
Dibandingkan dengan hasil sebelumnya yang diperoleh sepuluh tahun lalu, semua program mulai menggunakan lebih banyak memori. Xterm dulu memerlukan 4 MB, namun kini memerlukan 15 MB saat startup saja. Ada peningkatan konsumsi serupa untuk rxvt, yang sekarang membutuhkan 16 MB. Terminal Xfce membutuhkan 34 MB, tiga kali lebih besar dari sebelumnya, namun Terminal GNOME hanya memerlukan 20 MB. Tentu saja, semua pengujian sebelumnya dilakukan pada arsitektur 32-bit. Di LCA 2012 Rusty Russell , bahwa masih banyak alasan yang lebih halus yang dapat menjelaskan peningkatan konsumsi memori. Karena itu, kita sekarang hidup di masa di mana kita memiliki memori gigabyte, jadi kita akan mengelolanya.
Namun, saya merasa bahwa mengalokasikan lebih banyak memori ke sesuatu yang mendasar seperti terminal adalah pemborosan sumber daya. Program-program ini haruslah yang terkecil dari yang terkecil, harus dapat berjalan di “kotak” apa pun, bahkan di kotak sepatu, jika kita sampai pada titik di mana program tersebut harus dilengkapi dengan sistem Linux (dan Anda tahu bahwa hal itu akan terjadi) ) . Namun dengan angka-angka ini, penggunaan memori akan menjadi masalah di masa depan di lingkungan mana pun yang menjalankan banyak terminal selain beberapa terminal yang paling ringan dan kemampuannya paling terbatas. Untuk mengimbangi hal ini, Terminal GNOME, Konsole, urxvt, Terminator, dan Terminal Xfce memiliki mode Daemon yang memungkinkan Anda mengontrol banyak terminal melalui satu proses, sehingga membatasi konsumsi memorinya.
Selama pengujian, saya mendapatkan hasil lain yang tidak terduga mengenai baca-tulis disk: Saya berharap tidak melihat apa pun di sini, tetapi ternyata beberapa terminal menulis data paling banyak ke disk. Jadi, perpustakaan VTE sebenarnya menyimpan buffer gulir pada disk (fitur ini , dan ini masih terjadi). Namun tidak seperti implementasi sebelumnya, sekarang setidaknya data ini dienkripsi menggunakan AES256 GCM (). Namun muncul pertanyaan yang masuk akal: apa yang istimewa dari perpustakaan VTE sehingga memerlukan pendekatan implementasi yang tidak standar...
Kesimpulan
Pada bagian pertama artikel, kami menemukan bahwa terminal berbasis VTE memiliki serangkaian fitur yang bagus, namun sekarang kami melihat bahwa hal ini menimbulkan sejumlah biaya kinerja. Sekarang memori tidak menjadi masalah karena semua terminal VTE dapat dikontrol melalui proses Daemon, yang membatasi selera mereka. Namun, sistem lama yang memiliki keterbatasan fisik pada jumlah RAM dan buffer kernel mungkin masih memerlukan terminal versi lama, karena terminal tersebut mengonsumsi sumber daya yang jauh lebih sedikit. Meskipun terminal VTE berkinerja baik dalam pengujian throughput (pengguliran), latensi tampilannya berada di atas ambang batas yang ditetapkan dalam Panduan Pengguna GNOME. Pengembang VTE mungkin harus mempertimbangkan hal ini. Jika kita memperhitungkan bahwa bahkan bagi pengguna Linux pemula, menghadapi terminal tidak dapat dihindari, mereka dapat membuatnya lebih ramah pengguna. Bagi para ahli yang berpengalaman, beralih dari terminal default bahkan dapat mengurangi ketegangan mata dan kemampuan untuk menghindari cedera dan penyakit terkait pekerjaan di masa depan karena sesi kerja yang panjang. Sayangnya, hanya xterm dan mlterm lama yang membawa kita ke ambang ping ajaib 10 milidetik, yang tidak dapat diterima oleh banyak orang.
Pengukuran benchmark juga menunjukkan bahwa karena perkembangan lingkungan grafis Linux, pengembang harus membuat sejumlah kompromi. Beberapa pengguna mungkin ingin melihat window manager biasa karena memberikan pengurangan ping yang signifikan. Sayangnya, latensi untuk Wayland tidak dapat diukur: program Typometer yang saya gunakan dibuat untuk mencegah Wayland: memata-matai jendela lain. Saya berharap kinerja pengomposisian Wayland lebih baik daripada X.org, dan saya juga berharap di masa depan seseorang akan menemukan cara untuk mengukur latensi di lingkungan ini.
Sumber: www.habr.com