Muutama sana käännöstoimistoltamme: yleensä jokainen pyrkii kääntämään uusimmat materiaalit ja julkaisut, emmekä me ole poikkeus. Mutta terminaalit eivät ole jotain, jota päivitetään kerran viikossa. Siksi olemme kääntäneet sinulle Antoine Beauprén keväällä 2018 julkaistun artikkelin: nykyaikaisen mittakaavan huomattavasta "iästään" huolimatta materiaali ei mielestämme ole menettänyt merkitystään ollenkaan. Lisäksi tämä oli alun perin kahden artikkelin sarja, mutta päätimme yhdistää ne yhdeksi suureksi postaukseksi.
Päätteillä on erityinen paikka tietokonehistoriassa, mutta viime vuosikymmeninä ne ovat joutuneet selviytymään komentorivin rinnalla graafisten käyttöliittymien yleistyessä. korvasivat omansa , jotka puolestaan olivat modifikaatioita reikäkortteihin ja vaihtokytkimiin perustuvista järjestelmistä. Nykyaikaisissa jakeluissa on erilaisia pääteemulaattoreita kaikenmuotoisina ja -värisinä. Ja vaikka monet ovat tyytyväisiä työympäristönsä tarjoamaan vakiopäätteeseen, jotkut käyttävät ylpeänä suorastaan eksoottisia ohjelmistoja suosikkikuoren tai tekstieditorin suorittamiseen. Mutta kuten tästä artikkelista näemme, kaikkia päätteitä ei luotu samassa kuvassa: ne eroavat suuresti toiminnallisuudesta, koosta ja suorituskyvystä.
Joissakin päätelaitteissa on suorastaan yllättäviä tietoturva-aukkoja, ja useimmissa on täysin erilaiset toiminnot välilehtiliittymän tuesta komentosarjaan. Vaikka me , tämä artikkeli on päivitys aiempaan materiaaliin, joka auttaa lukijoita päättämään, mitä päätettä he käyttävät vuonna 2018. Artikkelin ensimmäinen puolisko vertailee ominaisuuksia ja toinen puolisko arvioi suorituskykyä.
Tässä ovat tarkistamani terminaalit:
Nämä eivät ehkä ole uusimmat versiot, koska kirjoitin kirjoittaessani vain vakaat koontiversiot, jotka pystyin julkaisemaan Debian 9:ssä tai Fedora 27:ssä. Ainoa poikkeus on Alacritty. Se on GPU-kiihdytettyjen päätteiden jälkeläinen ja on kirjoitettu tähän tehtävään epätavallisella ja uudella kielellä - Rust. Jätin verkkopäätteet pois arvostelustani (mukaan lukien ne ), koska alustavat testit osoittivat niiden erittäin huonon suorituskyvyn.
Unicode-tuki
Aloitin testit Unicode-tuella. Päätteiden ensimmäinen testi oli näyttää Unicode-merkkijono alkaen : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 ja 말." Tämä yksinkertainen testi osoittaa, voiko terminaali toimia oikein maailmanlaajuisesti. xterm terminaali ei näytä arabiaa oletuskokoonpanossa:
Oletuksena xterm käyttää klassista "kiinteää" fonttia, joka mukaan , sillä on "merkittävä Unicode-peitto vuodesta 1997". Tässä fontissa tapahtuu jotain, mikä saa merkin näyttämään tyhjänä kehyksenä, ja vasta kun tekstin fonttia kasvatetaan yli 20 pisteeseen, merkki alkaa lopulta näkyä oikein. Tämä "korjaus" kuitenkin katkaisee muiden Unicode-merkkien näytön:
Nämä kuvakaappaukset on otettu Fedora 27:ssä, koska se antoi parempia tuloksia kuin Debian 9, jossa jotkut vanhemmat pääteversiot (erityisesti mlterm) eivät pystyneet käsittelemään fontteja kunnolla. Onneksi tämä korjattiin myöhemmissä versioissa.
Huomaa nyt, kuinka rivi näkyy xtermissä. Osoittautuu, että symboli Mem ja sitä seuraava seemiläinen katso RTL-tyylisiä skriptejä (), joten teknisesti ne pitäisi näyttää oikealta vasemmalle. Verkkoselaimet, kuten Firefox 57, käsittelevät yllä olevaa riviä oikein. Yksinkertaisempi versio RTL-tekstistä on sana ""hepreaksi (). sanoo seuraavaa:
"Monet tietokoneohjelmat eivät pysty näyttämään kaksisuuntaista tekstiä oikein. Esimerkiksi heprealainen nimi "Sarah" koostuu kirjaimista sin (ש) (joka näkyy oikealla), sitten resh (ר) ja lopuksi he (ה) (jonka pitäisi näkyä vasemmalla)."
Monet päätteet eivät läpäise tätä testiä: Alacritty, VTE-peräiset Gnome- ja XFCE-päätteet, urxvt, st ja xterm näyttävät "Sara" käänteisessä järjestyksessä, ikään kuin olisimme kirjoittaneet nimen "Aras".
Toinen kaksisuuntaisten tekstien ongelma on se, että ne täytyy kohdistaa jotenkin, varsinkin kun on kyse RTL- ja LTR-tekstien sekoittamisesta. RTL-skriptien pitäisi toimia pääteikkunan oikealta puolelta, mutta mitä pitäisi tapahtua päätelaitteille, joiden oletuksena on LTR englanti? Useimmissa niistä ei ole erityisiä mekanismeja ja ne tasaavat kaiken tekstin vasemmalle (mukaan lukien Konsolessa). Poikkeuksia ovat pterm ja mlterm, jotka noudattavat standardeja ja kohdistavat tällaiset rivit oikealle.
Asennussuoja
Seuraava kriittinen ominaisuus, jonka olen tunnistanut, on työntösuoja. Vaikka on laajalti tiedossa, että loitsut kuten:
$ curl http://example.com/ | shovat koodin suorittamisen push-komentoja, harvat tietävät, että piilotetut komennot voivat livahtaa konsoliin, kun kopioidaan ja liitetään verkkoselaimesta, jopa huolellisen tarkastuksen jälkeen. osoittaa loistavasti, kuinka vaarattoman näköinen komento on:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitmuuttuu tällaiseksi haitaksi, kun se liitetään Hornin verkkosivustolta terminaaliin:
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.gitKuinka se toimii? Haitallinen koodi sisältyy lohkoon , joka siirretään pois käyttäjän näkyvistä CSS:n avulla.
on selvästi suunniteltu neutraloimaan tällaiset hyökkäykset. Tässä tilassa päätteet sulkevat liitetyn tekstin pariin erityisiin erotussarjoihin kertoakseen kuorelle tekstin alkuperästä. Tämä kertoo kuorelle, että se voi jättää huomiotta liitetyn tekstin sisältämät erikoismerkit. Kaikki päätteet takaisin kunnialliseen xtermiin tukevat tätä ominaisuutta, mutta liittäminen hakasulketussa tilassa vaatii tukea päätteessä käynnissä olevalta kuorelta tai sovellukselta. Esimerkiksi ohjelmistoja käyttävät (sama Bash), tarvitsee tiedoston ~/.inputrc:
set enable-bracketed-paste onValitettavasti Hornin testisivusto näyttää myös, kuinka tämä suojaus voidaan ohittaa itse tekstin muotoilun kautta ja päätyä käyttämään siihen ennenaikaisesti Haarukoitu-tilaa. Tämä toimii, koska jotkin päätteet eivät suodata pakojaksoja oikein ennen kuin lisäävät omiaan. Esimerkiksi omassani en koskaan pystynyt suorittamaan Konsole-testejä onnistuneesti edes oikeilla asetuksilla .inputrc tiedosto. Tämä tarkoittaa, että voit helposti saada järjestelmäkokoonpanosi vioittumaan tuettoman sovelluksen tai väärin määritetyn kuoren vuoksi. Tämä on erityisen vaarallista kirjautuessasi etäpalvelimiin, joissa huolellinen konfigurointi on harvinaisempaa, varsinkin jos tällaisia etäkoneita on useita.
Hyvä ratkaisu tähän ongelmaan on liitännän vahvistuslaajennus terminaalille urxvt, joka pyytää yksinkertaisesti lupaa lisätä minkä tahansa rivinvaihtoja sisältävän tekstin. En ole löytänyt turvallisempaa vaihtoehtoa Hornin kuvaamalle tekstihyökkäykselle.
Välilehdet ja profiilit
Suosittu ominaisuus tällä hetkellä on välilehtiliittymän tuki, jonka määrittelemme yhdeksi pääteikkunaksi, joka sisältää useita muita päätteitä. Tämä toiminto vaihtelee eri päätelaitteissa, ja vaikka perinteiset xterm-päätteet eivät tue välilehtiä ollenkaan, nykyaikaisemmissa pääteinkarnaatioissa, kuten Xfce Terminal, GNOME Terminal ja Konsole, on tämä toiminto. Urxvt tukee myös välilehtiä, mutta vain jos käytät laajennusta. Mutta itse välilehtien tuen suhteen Terminator on kiistaton johtaja: se ei vain tue välilehtiä, vaan voi myös järjestää päätteet missä tahansa järjestyksessä (katso kuva alla).
Toinen Terminatorin ominaisuus on kyky "ryhmittää" nämä välilehdet yhteen ja lähettää samat näppäinpainallukset useille päätelaitteille samanaikaisesti, mikä tarjoaa karkean työkalun joukkotoimintojen suorittamiseen useilla palvelimilla samanaikaisesti. Samanlainen ominaisuus on toteutettu myös Konsolessa. Jos haluat käyttää tätä ominaisuutta muissa päätelaitteissa, sinun on käytettävä kolmannen osapuolen ohjelmistoja, kuten , tai .
Välilehdet toimivat erityisen hyvin, kun ne yhdistetään profiileihin: sinulla voi esimerkiksi olla yksi välilehti sähköpostille, toinen chatille ja niin edelleen. Konsole Terminal ja GNOME Terminal tukevat tätä hyvin. Molemmat sallivat jokaisen välilehden käynnistää automaattisesti oman profiilinsa. Terminator tukee myös profiileja, mutta en löytänyt tapaa käynnistää tiettyjä ohjelmia automaattisesti, kun avaat tietyn välilehden. Muilla päätelaitteilla ei ole ollenkaan "profiilin" käsitettä.
Röyhelöt
Viimeinen asia, jonka käsittelen tämän artikkelin ensimmäisessä osassa, on päätteiden ulkonäkö. Esimerkiksi GNOME, Xfce ja urxvt tukevat läpinäkyvyyttä, mutta ne ovat hiljattain luopuneet taustakuvien tuesta, mikä pakottaa jotkin käyttäjät vaihtamaan päätelaitteeseen . Henkilökohtaisesti olen siihen tyytyväinen ja se on yksinkertainen X -resurssit, joka määrittää urxvt:n taustavärien perusjoukon. Epätyypilliset väriteemat voivat kuitenkin aiheuttaa ongelmia. Esimerkiksi, sovellusten kanssa и , koska he käyttävät jo omia värejään.
eivät tue värejä, ja uudet rajoittuivat usein 256 värin palettiin. Edistyneelle käyttäjälle, joka muotoilee päätelaitteitaan, komentotulkkikehotteet tai tilarivit monimutkaisilla tavoilla voivat olla ärsyttävää rajoitusta. seuraa millä päätelaitteilla on "True Color" -tuki. Testini vahvistavat, että st-, Alacrity- ja VTE-pohjaiset päätteet tukevat True Coloria täydellisesti. Muut terminaalit eivät menesty kovin hyvin tässä suhteessa, eivätkä itse asiassa näytä edes 256 väriä. Alla näet eron True Color -tuen GNOME-päätteissä, st ja xterm, jotka tekevät tässä hyvää työtä 256 väripalettillaan, ja urxvt, joka ei vain epäonnistu testissä, vaan näyttää jopa vilkkuvia merkkejä niiden sijaan.
Jotkut päätteet myös analysoivat tekstiä URL-mallien varalta, jotta linkit olisivat klikattavia. Tämä koskee kaikkia VTE-pohjaisia päätteitä, kun taas urxvt vaatii erityisen laajennuksen, joka muuntaa URL-osoitteet napsautuksella tai pikanäppäimen avulla. Muut päätteet Olen testannut näkyviä URL-osoitteita muilla tavoilla.
Lopuksi uusi suuntaus päätteissä on vierityspuskurin valinnaisuus. Esimerkiksi st:llä ei ole vierityspuskuria; oletetaan, että käyttäjä käyttää päätemultiplekseria, kuten tmux ja .
Alacrittysta puuttuu myös backscroll-puskurit, mutta sen tuki johtuu käyttäjien "laajasta palautteesta" tästä aiheesta. Näitä nousuja lukuun ottamatta jokainen testaamani päätelaite, jonka löysin, tukee käänteistä vieritystä.
välisummat
Materiaalin toisessa osassa (alkuperäisessä nämä olivat kaksi eri artikkelia - n. kaista) vertaamme suorituskykyä, muistin käyttöä ja latenssia. Mutta voimme jo nyt nähdä, että joissakin kyseisissä terminaaleissa on vakavia puutteita. Esimerkiksi käyttäjät, jotka työskentelevät säännöllisesti RTL-komentosarjojen kanssa, saattavat haluta harkita mltermiä ja ptermiä, koska he pystyvät käsittelemään samanlaisia tehtäviä paremmin kuin muut. Konsole toimi myös hyvin. Käyttäjät, jotka eivät työskentele RTL-skriptien kanssa, voivat valita jotain muuta.
Haitallisen koodin lisäämistä vastaan suojautumisen kannalta urxvt erottuu edukseen erityisestä suojauksestaan tämäntyyppisiä hyökkäyksiä vastaan, mikä vaikuttaa minusta ehdottomasti kätevältä. Niille, jotka etsivät kelloja ja pillejä, Konsole on tutustumisen arvoinen. Lopuksi on syytä huomata, että VTE on erinomainen tukikohta päätteille, mikä takaa värituen, URL-tunnistuksen ja niin edelleen. Ensi silmäyksellä suosikkiympäristösi mukana tuleva oletuspääte saattaa täyttää kaikki vaatimukset, mutta jätetään tämä kysymys avoimeksi, kunnes ymmärrämme suorituskyvyn.
Jatkamme keskustelua
Yleisesti ottaen päätteiden suorituskyky sinänsä saattaa tuntua kaukaa haetulta ongelmalta, mutta kuten käy ilmi, jotkin niistä osoittavat yllättävän korkeaa latenssia niin perustavanlaatuisille ohjelmistoille. Seuraavaksi tarkastellaan myös sitä, mitä perinteisesti kutsutaan "nopeudeksi" (itse asiassa tämä on vieritysnopeus) ja päätteen muistin kulutusta (varoituksella, että tämä ei ole niin kriittinen nykyään kuin vuosikymmeniä sitten).
viive
Päätteen suorituskyvyn perusteellisen tutkimuksen jälkeen tulin siihen tulokseen, että tärkein parametri tässä suhteessa on latenssi (ping). Hänen artikkelissaan Pavel Fatin tarkasteli eri tekstieditorien latenssia ja vihjasi, että päätteet voivat tässä suhteessa olla hitaampia kuin nopeimmat tekstieditorit. Tämä vihje sai minut lopulta suorittamaan omia testejäni ja kirjoittamaan tämän artikkelin.
Mutta mikä on latenssi ja miksi se on niin tärkeä? Artikkelissaan Fatin määritteli sen "viiveeksi näppäimen painalluksen ja vastaavan näytön päivityksen välillä" ja lainasi , jossa todetaan: "Tietokoneen näytöllä näkyvän visuaalisen palautteen viiveellä on tärkeä vaikutus konekirjoittajan käyttäytymiseen ja tyytyväisyyteen."
Fatin selittää, että tällä pingillä on syvempiä seurauksia kuin pelkkä tyytyväisyys: "kirjoittaminen hidastuu, virheitä tapahtuu enemmän ja silmien ja lihasten jännitys lisääntyy." Toisin sanoen suuri viive voi johtaa kirjoitusvirheisiin ja myös huonompaan koodin laatuun, koska se lisää kognitiivista kuormitusta aivoille. Mutta mikä pahinta on, että ping "lisää silmien ja lihasten rasitusta", mikä näyttää viittaavan Tulevaisuudessa (Ilmeisesti kirjoittaja tarkoittaa ongelmia silmien, selän, käsivarsien ja tietysti näön lihasten kanssa - noin. kaista) toistuvan stressin vuoksi.
Jotkut näistä vaikutuksista ovat olleet tiedossa jo pitkään, ja tulokset Ergonomics-lehdessä vuonna 1976 julkaistussa artikkelissa sanottiin, että 100 millisekunnin viive "heikentää merkittävästi kirjoitusnopeutta". Äskettäin esiteltiin GNOME-käyttöopas 10 millisekunnissa, ja jos menet pidemmälle, niin sitten osoittaa, että 1 millisekunti on ihanteellinen.
Fatin suoritti testinsä tekstieditoreilla; hän loi kannettavan instrumentin nimeltä , jota käytin testaamaan pingiä pääteemulaattoreissa. Muista, että testi suoritettiin simulaatiotilassa: todellisuudessa meidän on otettava huomioon sekä tulon (näppäimistö, USB-ohjain jne.) että lähdön (näytönohjainpuskuri, näyttö) latenssi. Fatinin mukaan tyypillisissä kokoonpanoissa se on noin 20 ms. Jos sinulla on pelilaitteita, voit saavuttaa tämän luvun vain 3 millisekunnissa. Koska meillä on jo niin nopea laitteisto, sovelluksen ei tarvitse lisätä omaa latenssiaan. Fatinin tavoitteena on nostaa sovelluksen latenssi 1 millisekuntiin tai jopa saavuttaa soittaminen ilman kuten .
Tässä ovat mittausteni tulokset sekä joitain Fatinin tuloksia osoittamaan, että kokeiluni on yhtäpitävä hänen testiensä kanssa:
Ensimmäinen asia, joka hämmästytti minua, oli vanhempien ohjelmien, kuten xterm ja mlterm, parempi vasteaika. Huonoimmalla rekisteriviiveellä (2,4 ms) ne suoriutuivat paremmin kuin nopein nykyaikainen pääte (10,6 ms st). Yksikään nykyaikainen päätelaite ei jää alle 10 millisekunnin kynnyksen. Etenkin Alacrity ei täytä "nopeimman saatavilla olevan pääteemulaattorin" -vaatimusta, vaikka sen pisteet ovat parantuneet sen ensimmäisen tarkastelun jälkeen vuonna 2017. Todellakin, projektin kirjoittajat ja pyrkivät parantamaan näyttöä. On myös huomattava, että GTK3:a käyttävä Vim on suuruusluokkaa hitaampi kuin GTK2-vastine. Tästä voimme päätellä, että GTK3 luo lisälatenssia, ja tämä näkyy kaikissa muissa sitä käyttävissä päätelaitteissa (Terminator, Xfce4 Terminal ja GNOME Terminal).
Erot eivät kuitenkaan välttämättä ole silmällä havaittavia. Kuten Fatin selittää, "sinun ei tarvitse olla tietoinen viiveestä, jotta se vaikuttaa sinuun." Fatin varoittaa myös keskihajonnasta: "kaikki latenssihäiriöt (värinä) aiheuttavat lisästressiä arvaamattomuudestaan johtuen."
Yllä oleva kaavio on otettu puhtaalla Debian 9:llä (venyttävä) kanssa . Tämä ympäristö tuottaa parhaat tulokset latenssitesteissä. Kuten käy ilmi, GNOME luo ylimääräisen 20 ms:n pingin kaikille mittauksille. Mahdollinen selitys tälle on sellaisten ohjelmien läsnäolo, joissa on syöttötapahtumien synkroninen käsittely. Fatin antaa esimerkin tällaisesta tapauksesta , joka lisää viivettä käsittelemällä kaikki syöttötapahtumat synkronisesti. Oletuksena GNOMEssa on myös ikkunanhallinta , joka luo ylimääräisen puskurointikerroksen, joka vaikuttaa pingiin ja lisää vähintään 8 millisekuntia latenssia.
Vieritysnopeus
Seuraava testi on perinteinen "nopeus"- tai "kaistanleveys"-testi, joka mittaa kuinka nopeasti pääte voi vierittää sivua ja näyttää suuria määriä tekstiä näytöllä. Testin mekaniikka vaihtelee; alkuperäinen testi oli yksinkertaisesti luoda sama tekstimerkkijono käyttämällä seq-komentoa. Muita testejä ovat Thomas E. Dickeyn (xterm ylläpitäjä) testi, joka toistuvasti . Toisessa katsauksessa terminaalin suorituskyvystä käyttää base32-koodattua satunnaisten tavujen merkkijonoa, joka lähetetään päätteelle cat. Luu pitää tällaista testiä "niin hyödyttömänä vertailukohtana kuin voi kuvitella" ja ehdottaa sen sijaan päätevasteen käyttöä ensisijaisena mittarina. Dickey kutsuu testiään myös harhaanjohtavaksi. Molemmat kirjoittajat kuitenkin myöntävät, että pääteikkunan kaistanleveys voi olla ongelma. Luu havaitsi Emacs Eshellin jumiutuneen suuria tiedostoja näytettäessä, ja Dickey optimoi päätelaitteen päästäkseen eroon xtremin visuaalisesta hitaudesta. Joten tässä testissä on vielä joitain ansioita, mutta koska renderöintiprosessi on hyvin erilainen terminaalista toiseen, sitä voidaan käyttää myös testikomponenttina muiden parametrien testaamiseen.
Tässä näemme rxvt- ja st-vedon kilpailijoita edellä, ja sitä seuraa paljon uudempi Alacrity, joka on suunniteltu suorituskykyyn keskittyen. Seuraavaksi tulevat Xfce (VTE-perhe) ja Konsole, jotka ovat lähes kaksi kertaa nopeampia. Viimeinen on xterm, joka on viisi kertaa hitaampi kuin rxvt. Testin aikana myös xterm aaltoili paljon, mikä vaikeutti ohitetun tekstin näkemistä, vaikka se olisikin sama rivi. Konsole oli nopea, mutta toisinaan hankala: näyttö jumiutui ajoittain näyttäen osittaista tekstiä tai ei näyttänyt sitä ollenkaan. Muut päätteet näyttivät merkkijonot selkeästi, mukaan lukien st, Alacrtty ja rxvt.
Dickey selittää, että suorituskykyerot johtuvat vierityspuskurien suunnittelusta eri päätteissä. Erityisesti hän syyttää rxvt:tä ja muita päätteitä "yleisten sääntöjen noudattamatta jättämisestä":
"Toisin kuin xterm, rxvt ei yrittänyt näyttää kaikkia päivityksiä. Jos se jää jälkeen, se kieltäytyy päivittämästä joitain päivityksiä. Tällä oli suurempi vaikutus näennäiseen vieritysnopeuteen kuin sisäiseen muistin organisointiin. Yksi haittapuoli oli, että ASCII-animaatio oli hieman epätarkka."
Dickey ehdottaa resurssin käyttöä korjatakseen tämän havaitun xtermin hitauden , jolloin xterm voi hylätä joitain näyttöpäivityksiä pysyäkseen virran mukana. Testini vahvistavat, että fastScroll parantaa suorituskykyä ja tuo xtermin rxvt:n tasolle. Tämä on kuitenkin melko karkea kainalosauva, kuten Dickey itse selittää: "joskus xterm - kuten konsole - näyttää pysähtyvän, kun se odottaa uusia näyttöpäivityksiä, kun jotkut on poistettu." Tässä mielessä näyttää siltä, että muut päätteet ovat löytäneet parhaan kompromissin nopeuden ja näytön eheyden välillä.
Resurssien kulutus
Riippumatta siitä, onko vieritysnopeutta järkevää pitää suorituskykymittarina, tämän testin avulla voimme simuloida päätteiden kuormitusta, mikä puolestaan antaa meille mahdollisuuden mitata muita parametreja, kuten muistin tai levyn käyttöä. Mittarit saatiin suorittamalla määritetty testi sek Python-prosessin valvonnan alla. Hän keräsi mittaritietoja varten ru_maxrss, määrä ru_oublock и ru_inblock ja yksinkertainen ajastin.
Tässä testissä ST on ykkönen pienimmällä keskimääräisellä muistinkulutuksella 8 MB, mikä ei ole yllättävää, kun otetaan huomioon, että suunnittelun pääidea on yksinkertaisuus. mlterm, xterm ja rxvt kuluttavat hieman enemmän - noin 12 Mt. Toinen huomionarvoinen tulos on Alakritty, joka vaatii 30 Mt toimiakseen. Sitten on VTE-perheen päätteitä, joiden luvut ovat 40-60 MB, mikä on melko paljon. Kulutus selittyy sillä, että näissä päätelaitteissa käytetään korkeamman tason kirjastoja, esimerkiksi GTK:ta. Konsole tulee viimeiseksi huikealla 65 Mt:n muistinkulutuksella testien aikana, vaikka tämä voidaan perustella sen erittäin laajalla ominaisuuksilla.
Verrattuna aikaisempiin, kymmenen vuotta sitten saatuihin tuloksiin, kaikki ohjelmat alkoivat kuluttaa huomattavasti enemmän muistia. Xterm vaati aiemmin 4 Mt, mutta nyt se vaatii 15 Mt vain käynnistyksen yhteydessä. Rxvt:n kulutus on kasvanut vastaavasti, ja se vaatii nyt 16 Mt. Xfce Terminal vie 34 Mt, mikä on kolme kertaa suurempi kuin ennen, mutta GNOME Terminal vaatii vain 20 Mt. Tietenkin kaikki aiemmat testit suoritettiin 32-bittisellä arkkitehtuurilla. LCA 2012:ssa Rusty Russell , että on monia hienovaraisempia syitä, jotka voivat selittää muistin kulutuksen kasvun. Tästä huolimatta elämme nyt aikaa, jossa meillä on gigatavua muistia, joten pärjäämme jotenkin.
En kuitenkaan voi olla ajattelematta, että muistin lisääminen johonkin niin olennaiseen kuin päätelaitteeseen on resurssien haaskausta. Näiden ohjelmien tulisi olla pienimmistä pienimmät, niiden pitäisi pystyä toimimaan missä tahansa "laatikossa", jopa kenkälaatikossa, jos koskaan tulemme siihen pisteeseen, että ne on varustettava Linux-järjestelmillä (ja tiedät sen olevan niin ) . Mutta näiden lukujen myötä muistin käytöstä tulee ongelma tulevaisuudessa missä tahansa ympäristössä, jossa on useita muita päätteitä kuin muutamia kevyimpiä ja rajoitetumpia ominaisuuksia. Tämän kompensoimiseksi GNOME Terminalissa, Konsolessa, urxvt:ssä, Terminatorissa ja Xfce Terminalissa on Daemon-tila, jonka avulla voit ohjata useita päätteitä yhden prosessin kautta ja rajoittaa niiden muistin kulutusta.
Testeissäni päädyin toiseen odottamattomaan tulokseen levyn luku-kirjoitus: Odotin, että tässä ei näkyisi yhtään mitään, mutta kävi ilmi, että jotkut päätteet kirjoittavat eniten levylle. Joten VTE-kirjasto itse asiassa pitää vierityspuskurin levyllä (tämä ominaisuus , ja tätä tapahtuu edelleen). Mutta toisin kuin vanhemmissa toteutuksissa, nyt ainakin nämä tiedot on salattu AES256 GCM:llä (). Mutta herää aiheellinen kysymys: mikä VTE-kirjastossa on niin erikoista, että se vaatii niin epätyypillistä toteutusta...
Johtopäätös
Artikkelin ensimmäisessä osassa havaitsimme, että VTE-pohjaisilla päätelaitteilla on hyvä joukko ominaisuuksia, mutta nyt näemme, että tähän liittyy joitain suorituskykykustannuksia. Nyt muisti ei ole ongelma, koska kaikkia VTE-päätteitä voidaan ohjata Daemon-prosessilla, mikä rajoittaa niiden ruokahalua. Vanhemmat järjestelmät, joissa on fyysisiä rajoituksia RAM-muistin ja ytimen puskureiden määrälle, saattavat kuitenkin tarvita aiempia versioita päätelaitteista, koska ne kuluttavat huomattavasti vähemmän resursseja. Vaikka VTE-päätteet suoriutuivat hyvin suorituskyvyn (vieritys) testeissä, niiden näytön latenssi on GNOME-käyttöoppaassa asetetun kynnyksen yläpuolella. VTE-kehittäjien pitäisi luultavasti ottaa tämä huomioon. Jos otamme huomioon, että jopa aloitteleville Linux-käyttäjille terminaalin kohtaaminen on väistämätöntä, he voivat tehdä siitä käyttäjäystävällisemmän. Kokeneille nörteille vaihtaminen oletuspäätteestä voi jopa tarkoittaa vähemmän silmien rasitusta ja kykyä välttää tulevat työtapaturmat ja sairaudet pitkien työistuntojen takia. Valitettavasti vain vanhat xterm ja mlterm tuovat meidät 10 millisekunnin maagiseen ping-kynnykseen, mikä ei ole monien mielestä hyväksyttävää.
Benchmark-mittaukset osoittivat myös, että Linuxin graafisten ympäristöjen kehityksen vuoksi kehittäjien oli tehtävä useita kompromisseja. Jotkut käyttäjät saattavat haluta tarkastella tavallisia ikkunoiden hallintaohjelmia, koska ne vähentävät merkittävästi pingistä. Valitettavasti Waylandin viivettä ei voitu mitata: käyttämäni Typometer-ohjelma luotiin sitä varten, mitä Wayland on suunniteltu estämään: muiden ikkunoiden vakoilua. Toivon, että Wayland-kompositio toimii paremmin kuin X.org, ja toivon myös, että tulevaisuudessa joku löytää tavan mitata latenssia tässä ympäristössä.
Lähde: will.com