Çeviri büromuzdan birkaç kelime: Genellikle herkes en son materyalleri ve yayınları çevirmeye çalışır ve biz de bir istisna değiliz. Ama terminaller haftada bir güncellenen bir şey değil. Bu nedenle, Antoine Beaupré'nin 2018 baharında yayınlanan bir makalesini sizin için tercüme ettik: modern standartlara göre hatırı sayılır "yaşına" rağmen, bize göre materyal alaka düzeyini hiç kaybetmedi. Ek olarak, bu aslında iki makaleden oluşan bir seriydi ancak bunları büyük bir gönderide birleştirmeye karar verdik.
Terminallerin bilgisayar tarihinde özel bir yeri vardır, ancak son yıllarda grafiksel arayüzler her yerde yaygınlaştıkça komut satırının yanında hayatta kalmak zorunda kaldılar. kendilerinin yerini aldı bu da delikli kartlara ve geçiş anahtarlarına dayalı sistemlerin bir modifikasyonuydu. Modern dağıtımlar, tüm şekil ve renklerde çeşitli terminal emülatörleriyle birlikte gelir. Birçoğu çalışma ortamlarının sağladığı standart terminalden memnunken, bazıları en sevdikleri kabuk veya metin düzenleyiciyi çalıştırmak için düpedüz egzotik yazılımı gururla kullanıyor. Ancak bu makaleden göreceğimiz gibi, tüm terminaller aynı görüntüde oluşturulmamıştır: işlevsellik, boyut ve performans açısından büyük farklılıklar gösterirler.
Bazı terminallerde düpedüz şaşırtıcı güvenlik açıkları vardır, ayrıca çoğu, sekmeli arayüz desteğinden komut dosyası oluşturmaya kadar tamamen farklı işlevlere sahiptir. Bize ragmen , bu makale, okuyucuların 2018'de hangi terminali kullanacaklarını belirlemelerine yardımcı olacak önceki materyalin bir güncellemesidir. Makalenin ilk yarısı özellikleri karşılaştırır, ikinci yarısı ise performansı değerlendirir.
İşte incelediğim terminaller:
Bu yazının yazıldığı sırada Debian 9 veya Fedora 27'de kullanıma sunabildiğim kararlı yapılarla sınırlı olduğum için bunlar en son sürümler olmayabilir. Bunun tek istisnası Alacritty'dir. GPU hızlandırmalı terminallerin soyundan gelir ve bu görev için alışılmadık ve yeni bir dil olan Rust ile yazılmıştır. Web terminallerini incelememin dışında tuttum (üzerindekiler dahil) ), çünkü ön testler son derece zayıf performanslarını gösterdi.
Unicode desteği
Testlerime Unicode desteğiyle başladım. Terminallerin ilk testi Unicode dizesini görüntülemekti. : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 ve 말.” Bu basit test, terminalin dünya çapında doğru şekilde çalışıp çalışmadığını gösterir. xterm terminali Arapça karakteri görüntülemiyor varsayılan yapılandırmada:
Varsayılan olarak xterm, aşağıdakilere göre klasik "sabit" yazı tipini kullanır: , "1997'den beri önemli bir Unicode kapsamına" sahiptir. Bu yazı tipinde, karakterin boş bir çerçeve olarak görünmesine neden olan bir şeyler oluyor ve yalnızca metin yazı tipi 20'den fazla noktaya yükseltildiğinde karakter nihayet doğru şekilde görüntülenmeye başlıyor. Ancak bu "düzeltme" diğer Unicode karakterlerin görüntüsünü bozar:
Bu ekran görüntüleri, bazı eski terminal sürümlerinin (özellikle mlterm) yazı tiplerini düzgün şekilde işleyemediği Debian 27'dan daha iyi sonuçlar verdiği için Fedora 9'de alınmıştır. Neyse ki bu sonraki sürümlerde düzeltildi.
Şimdi satırın xterm'de nasıl görüntülendiğine dikkat edin. Görünüşe göre Mem sembolü ve aşağıdaki Semitik RTL tarzı komut dosyalarına bakın (), bu nedenle teknik olarak sağdan sola görüntülenmeleri gerekir. Firefox 57 gibi web tarayıcıları yukarıdaki satırı doğru şekilde işler. RTL metninin daha basit bir versiyonu " kelimesidir" İbranice (). şunları söylüyor:
“Birçok bilgisayar programı çift yönlü metni doğru şekilde görüntüleyemiyor. Örneğin, İbranice "Sarah" adı sin (ש) (sağda görünür), ardından resh (ר) ve son olarak o (ה) (solda görünmesi gereken) karakterlerinden oluşur."
Birçok terminal bu testi geçemez: Alacritty, VTE'den türetilmiş Gnome ve XFCE terminalleri, urxvt, st ve xterm, sanki adı "Aras" yazmışız gibi "Sara"yı ters sırada görüntüler.
Çift yönlü metinlerle ilgili bir başka sorun da, özellikle RTL ve LTR metinlerinin karıştırılması söz konusu olduğunda, bunların bir şekilde hizalanması gerekmesidir. RTL komut dosyaları terminal penceresinin sağ tarafından çalıştırılmalıdır, ancak varsayılan olarak LTR İngilizce'yi kullanan terminaller için ne olmalıdır? Çoğunun herhangi bir özel mekanizması yoktur ve tüm metni sola hizalar (Konsole dahil). İstisnalar, standartlara uyan ve bu çizgileri doğru hizalayan pterm ve mlterm'dir.
Ekleme koruması
Belirlediğim bir sonraki kritik özellik, takılmaya karşı korumadır. Her ne kadar büyülerin şu şekilde olduğu yaygın olarak bilinse de:
$ curl http://example.com/ | shKod yürütme push komutları olduğundan, çok az kişi, gizli komutların, dikkatli bir incelemeden sonra bile bir web tarayıcısından kopyalayıp yapıştırırken konsola gizlice girebileceğini biliyor. komutun ne kadar zararsız göründüğünü zekice gösteriyor:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitHorn'un web sitesinden terminale yapıştırıldığında büyük bir sıkıntıya dönüşüyor:
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.gitNasıl çalışır? Kötü amaçlı kod bloğa dahil edildi , CSS kullanılarak kullanıcının görüş alanının dışına taşınır.
açıkça bu tür saldırıları etkisiz hale getirmek için tasarlanmıştır. Bu modda, terminaller, kabuğa metnin kökeni hakkında bilgi vermek için yapıştırılan metni bir çift özel kaçış dizisi içine alır. Bu, kabuğa, yapıştırılan metnin içerebileceği özel karakterleri yok sayabileceğini bildirir. Saygıdeğer xterm'e geri dönen tüm terminaller bu özelliği destekler, ancak Parantezli modda yapıştırma, kabuktan veya terminalde çalışan uygulamadan destek gerektirir. Örneğin, yazılım kullanan (aynı Bash), bir dosyaya ihtiyacı var ~/.inputrc:
set enable-bracketed-paste onNe yazık ki, Horn'un test sitesi aynı zamanda metin formatının kendisi aracılığıyla bu korumanın nasıl atlanacağını ve buna zamanından önce Parantezli modun nasıl uygulanacağını da gösteriyor. Bu işe yarar çünkü bazı terminaller, kendi kaçış dizilerini eklemeden önce kaçış dizilerini doğru şekilde filtrelemez. Örneğin, benimkinde Konsole testlerini doğru konfigürasyonla bile başarıyla tamamlayamadım. .inputrc dosya. Bu, desteklenmeyen bir uygulama veya yanlış yapılandırılmış bir kabuk nedeniyle sistem yapılandırmanızın kolayca bozulmasına neden olabileceğiniz anlamına gelir. Bu, özellikle bu tür çok sayıda uzak makineniz varsa, dikkatli yapılandırma çalışmasının daha az yaygın olduğu uzak sunucularda oturum açarken özellikle tehlikelidir.
Bu soruna iyi bir çözüm, terminal için yapıştırma onayı eklentisidir urxvt, bu sadece yeni satırlar içeren herhangi bir metni eklemek için izin ister. Horn'un anlattığı metin saldırısı için daha güvenli bir seçenek bulamadım.
Sekmeler ve profiller
Şu anda popüler olan bir özellik, diğer birçok terminali içeren bir terminal penceresi olarak tanımlayacağımız sekmeli bir arayüzün desteklenmesidir. Bu işlev farklı terminaller için farklılık gösterir ve geleneksel xterm terminalleri sekmeleri hiç desteklemese de, Xfce Terminali, GNOME Terminali ve Konsole gibi daha modern terminal enkarnasyonlarında bu işlev bulunur. Urxvt ayrıca sekmeleri de destekler, ancak yalnızca bir eklenti kullanıyorsanız. Ancak sekme desteği açısından Terminatör tartışmasız liderdir: yalnızca sekmeleri desteklemekle kalmaz, aynı zamanda terminalleri herhangi bir sıraya göre düzenleyebilir (aşağıdaki resme bakın).
Terminatörün bir başka özelliği de bu sekmeleri bir arada "gruplama" ve aynı tuş vuruşlarını aynı anda birden fazla terminale göndererek birden fazla sunucuda aynı anda toplu işlemler gerçekleştirmek için basit bir araç sağlamasıdır. Benzer bir özellik Konsole'da da uygulanmıştır. Bu özelliği diğer terminallerde kullanmak için aşağıdaki gibi üçüncü taraf yazılımları kullanmanız gerekir: , veya .
Sekmeler, profillerle eşleştirildiğinde özellikle iyi çalışır: örneğin, e-posta için bir sekmeniz, sohbet için başka bir sekmeniz vb. olabilir. Bu, Konsole Terminali ve GNOME Terminali tarafından iyi bir şekilde desteklenir. Her ikisi de her sekmenin otomatik olarak kendi profilini başlatmasına izin verir. Terminatör ayrıca profilleri de destekliyor ancak belirli bir sekmeyi açtığınızda belirli programları otomatik olarak başlatmanın bir yolunu bulamadım. Diğer terminallerde “profil” kavramı hiç yoktur.
Fırfırlar
Bu makalenin ilk bölümünde ele alacağım son şey terminallerin görünümüdür. Örneğin GNOME, Xfce ve urxvt şeffaflığı destekliyor ancak son zamanlarda arka plan resimlerine yönelik desteğin kesilmesi bazı kullanıcıları terminale geçmeye zorluyor . Şahsen ben bundan memnunum ve bu çok basit xresourcesurxvt için temel arka plan renkleri kümesini ayarlayan. Ancak standart dışı renk temaları da sorun yaratabilmektedir. Örneğin, uygulamalarla и çünkü zaten kendi renklerini kullanıyorlar.
renkleri desteklemiyordu ve yenileri genellikle 256 renkli bir paletle sınırlıydı. Terminallerini, kabuk istemlerini veya durum çubuklarını karmaşık şekillerde şekillendiren ileri düzey kullanıcılar için can sıkıcı bir sınırlama olabilir. hangi terminallerin "Gerçek Renk" desteğine sahip olduğunu izler. Testlerim st, Alacritty ve VTE tabanlı terminallerin True Color'ı mükemmel şekilde desteklediğini doğruladı. Diğer terminaller bu konuda pek başarılı değiller ve hatta 256 renk bile göstermiyorlar. Aşağıda, 256 renk paletiyle bu işi iyi yapan GNOME terminallerindeki Gerçek Renk desteği, st ve xterm ile yalnızca testi geçemeyen, hatta bunların yerine bazı yanıp sönen karakterler gösteren urxvt arasındaki farkı görebilirsiniz.
Bazı terminaller ayrıca bağlantıları tıklanabilir hale getirmek için metni URL kalıpları açısından analiz eder. Bu, VTE'den türetilen tüm terminaller için geçerlidir; ancak urxvt, URL'leri bir tıklamayla veya bir klavye kısayolu kullanarak dönüştürecek özel bir eklenti gerektirir. Test ettiğim diğer terminaller URL'leri başka şekillerde gösteriyor.
Son olarak, terminallerdeki yeni bir trend, kaydırma arabelleğinin isteğe bağlı olmasıdır. Örneğin st'nin kaydırma arabelleği yoktur; kullanıcının tmux gibi bir terminal çoklayıcı kullanacağı varsayılmaktadır ve .
Alacritty'de ayrıca geri kaydırma arabellekleri de yok, ancak kullanıcılardan bu konuyla ilgili "kapsamlı geri bildirimler" alması nedeniyle desteklenmektedir. Bu başlangıçların dışında, test ettiğim ve bulabildiğim her terminal ters kaydırmayı destekliyor.
alt toplamlar
Metnin ikinci bölümünde (orijinalde bunlar iki farklı makaleydi - yakl. Lane) performansı, bellek kullanımını ve gecikmeyi karşılaştıracağız. Ancak söz konusu terminallerin bazılarının ciddi eksikliklerinin olduğunu şimdiden görebiliyoruz. Örneğin, düzenli olarak RTL komut dosyalarıyla çalışan kullanıcılar, benzer görevleri diğerlerinden daha iyi hallettikleri için mlterm ve pterm'i dikkate almak isteyebilirler. Konsole da iyi performans gösterdi. RTL komut dosyalarıyla çalışmayan kullanıcılar başka bir şey seçebilir.
Kötü amaçlı kod eklenmesine karşı koruma açısından urxvt, bu tür saldırılara karşı özel koruma uygulaması nedeniyle öne çıkıyor ve bu bana kesinlikle uygun görünüyor. Biraz özellik arayanlar için Konsole bir göz atmaya değer. Son olarak, VTE'nin terminaller için mükemmel bir temel olduğunu ve renk desteğini, URL tanımayı vb. garanti ettiğini belirtmekte fayda var. İlk bakışta favori ortamınızla birlikte gelen varsayılan terminal tüm gereksinimleri karşılayabilir ancak performansı anlayana kadar bu soruyu açık bırakalım.
Sohbete devam ediyoruz
Genel olarak, terminallerin performansı kendi başına zorlayıcı bir sorun gibi görünebilir, ancak ortaya çıktığı gibi, bazılarının bu kadar temel türdeki yazılımlar için şaşırtıcı derecede yüksek gecikme süresi sergilediği ortaya çıktı. Ayrıca bundan sonra geleneksel olarak "hız" olarak adlandırılan şeye (aslında bu kaydırma hızıdır) ve terminalin bellek tüketimine (bunun bugün onlarca yıl önce olduğu kadar kritik olmadığı uyarısıyla) bakacağız.
gecikme
Terminal performansını kapsamlı bir şekilde inceledikten sonra bu konudaki en önemli parametrenin gecikme (ping) olduğu sonucuna vardım. Makalesinde Pavel Fatin çeşitli metin editörlerinin gecikmesini inceledi ve bu bağlamda terminallerin en hızlı metin editörlerinden daha yavaş olabileceğini ima etti. Sonunda beni kendi testlerimi yapmaya ve bu makaleyi yazmaya yönlendiren de bu ipucuydu.
Peki gecikme nedir ve neden bu kadar önemlidir? Fatin, makalesinde bunu "bir tuşa basılması ile ilgili ekran güncellemesi arasındaki gecikme" olarak tanımladı ve alıntı yaptı: , şunu belirtiyor: "Bilgisayar ekranındaki görsel geri bildirimdeki gecikme, daktilo davranışı ve memnuniyeti üzerinde önemli bir etkiye sahiptir."
Fatin, bu ping'in tatminden daha derin sonuçlara yol açtığını açıklıyor: "Yazma işlemi yavaşlıyor, daha fazla hata meydana geliyor ve göz ve kas gerginliği artıyor." Başka bir deyişle, büyük bir gecikme, beyinde ek bilişsel yüke neden olacağından yazım hatalarına ve aynı zamanda kod kalitesinin düşmesine neden olabilir. Ancak daha da kötüsü, ping'in "göz ve kas gerginliğini artırması", ki bu da şu anlama geliyor: gelecekte (Görünüşe göre yazar, göz kasları, sırt, kollar ve tabii ki görme ile ilgili sorunları kastediyor - yaklaşık. Lane) tekrarlayan stres nedeniyle.
Bu etkilerin bazıları uzun zamandır bilinmektedir ve sonuçları 1976 yılında Ergonomics dergisinde yayınlanan bir makale, 100 milisaniyelik bir gecikmenin "yazma hızını önemli ölçüde bozduğunu" söyledi. Yakın zamanda GNOME Kullanıcı Kılavuzu tanıtıldı 10 milisaniye içinde ve daha ileri giderseniz, o zaman 1 milisaniyenin ideal olduğunu gösteriyor.
Fatin testlerini metin editörleri üzerinde gerçekleştirdi; adında taşınabilir bir enstrüman yarattı Terminal emülatörlerinde ping'i test etmek için kullandım. Testin simülasyon modunda yapıldığını unutmayın: gerçekte hem giriş (klavye, USB denetleyici vb.) hem de çıkış (ekran kartı arabelleği, monitör) gecikmesini hesaba katmamız gerekir. Fatin'e göre tipik konfigürasyonlarda bu süre yaklaşık 20 ms'dir. Oyun ekipmanınız varsa bu rakama yalnızca 3 milisaniyede ulaşabilirsiniz. Zaten çok hızlı bir donanıma sahip olduğumuz için uygulamanın kendi gecikmesini eklemesine gerek yok. Fatin'in hedefi uygulama gecikmesini 1 milisaniyeye çıkarmak, hatta aramayı , nasıl .
Benim ölçümlerimin sonuçları ve Fatin'in bazı sonuçları, benim deneyimimin onun testleriyle uyumlu olduğunu göstermek için aşağıda verilmiştir:
Beni etkileyen ilk şey, xterm ve mlterm gibi eski programların daha iyi tepki süresiydi. En kötü kayıt gecikmesiyle (2,4 ms), en hızlı modern terminalden (st için 10,6 ms) daha iyi performans gösterdiler. Hiçbir modern terminal 10 milisaniye eşiğinin altına düşmez. Özellikle Alacritty, 2017'deki ilk incelemesinden bu yana puanları artmasına rağmen "mevcut en hızlı terminal emülatörü" iddiasını karşılayamıyor. Aslında projenin yazarları ve ekranı iyileştirmek için çalışıyoruz. Ayrıca GTK3 kullanan Vim'in GTK2 muadilinden çok daha yavaş olduğunu da belirtmek gerekir. Buradan GTK3'ün ek gecikme yarattığı sonucuna varabiliriz ve bu, onu kullanan diğer tüm terminallere (Terminatör, Xfce4 Terminali ve GNOME Terminali) yansır.
Ancak farklılıklar gözle görülmeyebilir. Fatin'in açıkladığı gibi, "Sizi etkilemesi için gecikmenin farkında olmanıza gerek yok." Fatin ayrıca standart sapma konusunda da uyarıyor: "Gecikmedeki herhangi bir rahatsızlık (jitter), öngörülemezliğinden dolayı ek stres yaratır."
Yukarıdaki grafik saf Debian 9 (esnek) ile alınmıştır ve . Bu ortam gecikme testlerinde en iyi sonuçları üretir. GNOME'un tüm ölçümler için 20 ms'lik ek bir ping oluşturduğu ortaya çıktı. Bunun olası bir açıklaması, giriş olaylarının eşzamanlı olarak işlendiği programların varlığıdır. Fatin böyle bir duruma örnek veriyor , tüm giriş olaylarını eşzamanlı olarak işleyerek bir gecikme ekler. Varsayılan olarak GNOME ayrıca bir pencere yöneticisiyle birlikte gelir Bu, ping'i etkileyen ve en az 8 milisaniyelik gecikme süresi ekleyen ek bir arabellekleme katmanı oluşturur.
Kaydırma hızı
Bir sonraki test, terminalin ekranda büyük miktarda metin görüntülerken bir sayfayı ne kadar hızlı kaydırabildiğini ölçen geleneksel bir "hız" veya "bant genişliği" testidir. Testin mekaniği değişiklik gösterir; Orijinal test, seq komutunu kullanarak aynı metin dizesini oluşturmaktı. Diğer testler arasında Thomas E. Dickey'nin (xterm sürdürücü) testi yer alır; . Terminal performansının başka bir incelemesinde cat kullanılarak terminale gönderilen base32 kodlu rastgele bayt dizesini kullanır. Luu, böyle bir testin "hayal edilebilecek kadar işe yaramaz bir kıyaslama" olduğunu düşünüyor ve bunun yerine terminal yanıtının birincil ölçüm olarak kullanılmasını öneriyor. Dickey ayrıca testinin yanıltıcı olduğunu söylüyor. Ancak her iki yazar da terminal penceresi bant genişliğinin bir sorun olabileceğini kabul ediyor. Luu, Emacs Eshell'in büyük dosyaları görüntülerken donduğunu keşfetti ve Dickey, xtrerm'in görsel yavaşlığından kurtulmak için terminali optimize etti. Dolayısıyla bu testin hâlâ bazı yararları var, ancak işleme süreci terminalden terminale çok farklı olduğundan, diğer parametreleri test etmek için bir test bileşeni olarak da kullanılabilir.
Burada rxvt ve st'nin rekabette öne geçtiğini, ardından da performans odaklı tasarlanan çok daha yeni Alacritty'nin geldiğini görüyoruz. Sırada neredeyse iki kat daha hızlı olan Xfce (VTE ailesi) ve Konsole var. Sonuncusu, rxvt'den beş kat daha yavaş olan xterm'dir. Test sırasında xterm de çok fazla dalgalandı ve aynı satır olsa bile geçen metnin görülmesini zorlaştırdı. Konsole hızlıydı ama bazen yanıltıcıydı: ekran zaman zaman donuyordu, kısmi metin gösteriyordu ya da hiç göstermiyordu. St, Alacritty ve rxvt dahil olmak üzere diğer terminaller dizeleri açıkça gösteriyordu.
Dickey, performans farklılıklarının farklı terminallerdeki kaydırma arabelleklerinin tasarımından kaynaklandığını açıklıyor. Özellikle rxvt ve diğer terminalleri "genel kurallara uymamakla" suçluyor:
“Xterm'den farklı olarak rxvt tüm güncellemeleri görüntülemeye çalışmadı. Eğer geride kalırsa, bazı güncellemelerin yetişmesini reddedecektir. Bunun görünür kaydırma hızı üzerinde dahili bellek organizasyonundan daha büyük bir etkisi oldu. Bir dezavantajı, ASCII animasyonunun biraz belirsiz olmasıydı."
Dickey, algılanan bu xterm durgunluğunu düzeltmek için kaynağın kullanılmasını öneriyor , xterm'in akışa ayak uydurmak için bazı ekran güncellemelerini atmasına olanak tanır. Testlerim fastScroll'un performansı artırdığını ve xterm'i rxvt ile aynı seviyeye getirdiğini doğruluyor. Ancak bu, Dickey'in kendisinin de açıkladığı gibi oldukça zorlu bir destek: "bazen xterm - tıpkı konsole gibi - bazıları kaldırıldıktan sonra yeni ekran güncellemelerini beklerken duruyor gibi görünüyor." Bu bağlamda, diğer terminallerin hız ve ekran bütünlüğü arasındaki en iyi uzlaşmayı bulduğu görülüyor.
Kaynak tüketimi
Kaydırma hızını bir performans ölçüsü olarak dikkate almanın mantıklı olup olmadığına bakılmaksızın, bu test, terminallerdeki yükü simüle etmemize olanak tanır ve bu da bellek veya disk kullanımı gibi diğer parametreleri ölçmemize olanak tanır. Metrikler belirtilen test çalıştırılarak elde edildi seq Python süreç izleme altında. Sayaç verilerini topladı için ru_maxrss, Miktar ru_oublock и ru_inblock ve basit bir zamanlayıcı.
Bu testte ST, 8 MB ile en düşük ortalama bellek tüketimiyle ilk sırayı alıyor. Tasarımın ana fikrinin sadelik olduğu düşünülürse bu durum pek de şaşırtıcı değil. mlterm, xterm ve rxvt biraz daha fazla tüketir - yaklaşık 12 MB. Bir diğer dikkate değer sonuç, çalışması için 30 MB gerektiren Alacritty'dir. Ayrıca VTE ailesinin 40 ila 60 MB arası rakamlara sahip terminalleri var ki bu oldukça fazla. Bu tüketim, bu terminallerin GTK gibi daha üst düzey kütüphaneleri kullanması gerçeğiyle açıklanabilir. Konsole, testler sırasında 65 MB'lık devasa bir bellek tüketimiyle son sırada yer alıyor, ancak bu, çok çeşitli özellikleriyle haklı çıkarılabilir.
On yıl önce elde edilen önceki sonuçlarla karşılaştırıldığında, tüm programlar fark edilir derecede daha fazla bellek tüketmeye başladı. Xterm eskiden 4 MB gerektiriyordu, ancak şimdi yalnızca başlangıçta 15 MB gerektiriyor. Artık kutudan çıktığı haliyle 16 MB gerektiren rxvt için de tüketimde benzer bir artış var. Xfce Terminali, öncekinden üç kat daha fazla olan 34 MB yer kaplıyor, ancak GNOME Terminali yalnızca 20 MB gerektiriyor. Elbette daha önceki tüm testler 32 bit mimari üzerinde gerçekleştirildi. LCA 2012'de Rusty Russell Bellek tüketimindeki artışı açıklayabilecek çok daha ince nedenler var. Bununla birlikte, artık gigabaytlarca hafızaya sahip olduğumuz bir zamanda yaşıyoruz, bu yüzden bir şekilde idare edeceğiz.
Ancak terminal gibi temel bir şeye daha fazla bellek ayırmanın kaynak israfı olduğunu düşünmeden edemiyorum. Bu programlar en küçüğün en küçüğü olmalı, herhangi bir “kutuda”, hatta bir ayakkabı kutusunda bile çalışabilmeli, eğer Linux sistemleriyle donatılmaları gereken noktaya gelirsek (ve öyle olacağını biliyorsunuz) ). Ancak bu rakamlarla birlikte, en hafif ve yetenekleri en sınırlı birkaç terminal dışında birden fazla terminal çalıştıran herhangi bir ortamda bellek kullanımı gelecekte bir sorun haline gelecektir. Bunu telafi etmek için GNOME Terminali, Konsole, urxvt, Terminator ve Xfce Terminali, birden fazla terminali tek bir işlem aracılığıyla kontrol etmenize olanak tanıyan ve bellek tüketimini sınırlayan bir Daemon moduna sahiptir.
Testlerim sırasında disk okuma-yazma ile ilgili beklenmedik bir sonuca daha ulaştım: Burada hiçbir şey göremeyeceğimi bekliyordum ama bazı terminallerin en büyük verileri diske yazdığı ortaya çıktı. Yani, VTE kütüphanesi aslında diskte bir kaydırma arabelleği tutar (bu özellik ve bu hala oluyor). Ancak eski uygulamaların aksine, artık en azından bu veriler AES256 GCM (). Ancak makul bir soru ortaya çıkıyor: VTE kütüphanesini bu kadar özel kılan şey, uygulama için bu kadar standart dışı bir yaklaşım gerektirmesi...
Sonuç
Makalenin ilk bölümünde VTE tabanlı terminallerin iyi bir dizi özelliğe sahip olduğunu gördük ancak şimdi bunun bazı performans maliyetlerini de beraberinde getirdiğini görüyoruz. Artık hafıza sorun değil çünkü tüm VTE terminalleri bir Daemon süreci aracılığıyla kontrol edilebiliyor, bu da onların iştahını sınırlıyor. Bununla birlikte, RAM ve çekirdek arabelleklerinin miktarı konusunda fiziksel sınırlamalara sahip olan eski sistemler, önemli ölçüde daha az kaynak tükettiklerinden, terminallerin daha eski sürümlerine ihtiyaç duyabilirler. Her ne kadar VTE terminalleri üretim (kaydırma) testlerinde iyi performans gösterse de, görüntüleme gecikmeleri GNOME Kullanıcı Kılavuzunda belirlenen eşiğin üzerindedir. VTE geliştiricilerinin muhtemelen bunu dikkate alması gerekir. Acemi Linux kullanıcılarının bile bir terminalle karşılaşmasının kaçınılmaz olduğunu dikkate alırsak, onu daha kullanıcı dostu hale getirebilirler. Deneyimli meraklılar için, varsayılan terminalden geçiş, daha az göz yorgunluğu ve gelecekte uzun çalışma seansları nedeniyle işle ilgili yaralanmalardan ve hastalıklardan kaçınma yeteneği anlamına bile gelebilir. Maalesef yalnızca eski xterm ve mlterm bizi 10 milisaniyelik sihirli ping eşiğine getiriyor ki bu çoğu kişi için kabul edilemez.
Karşılaştırmalı ölçümler ayrıca Linux grafik ortamlarının gelişmesi nedeniyle geliştiricilerin bir takım tavizler vermek zorunda kaldığını da gösterdi. Bazı kullanıcılar, önemli ölçüde ping düşüşü sağladıklarından normal pencere yöneticilerine bakmak isteyebilir. Ne yazık ki Wayland için gecikmeyi ölçmek mümkün değildi: Kullandığım Tipometre programı, Wayland'in engellemek üzere tasarlandığı şey için oluşturuldu: diğer pencereleri gözetlemek. Wayland birleştirmenin X.org'dan daha iyi performans gösterdiğini umuyorum ve gelecekte birisinin bu ortamdaki gecikmeyi ölçmenin bir yolunu bulacağını da umuyorum.
Kaynak: habr.com