Et par ord fra vores oversættelsesbureau: normalt stræber alle efter at oversætte de nyeste materialer og publikationer, og vi er ingen undtagelse. Men terminaler er ikke noget, der opdateres hver uge. Derfor har vi oversat artikel af Antoine Beaulieu, der blev offentliggjort foråret 2018: på trods af dens respektable 'alder' i moderne målestok mener vi, at materialet er helt aktuelt. Desuden er det i originalen en serie på to artikler, men vi har besluttet at kombinere dem til et stort indlæg.
Terminaler har en særlig plads i computerhistorien, men i de seneste årtier har de været 'nødt til' bogstaveligt talt at overleve sammen med kommandoprompten midt i den udbredte brug af grafiske brugerflader. erstatte deres , som i sin tur var en modifikation af systemer baseret på perforerede kort og drejekontakter. Moderne distributioner leveres med et væld af terminalemulatorer i alle former og farver. Og mens mange er tilfredse med den standardterminal, der leveres med deres arbejdsområde, bruger nogle stolt eksotisk software til at køre deres foretrukne shell eller teksteditor. Men som vi vil se i denne artikel, er ikke alle terminaler skabt ens: de varierer meget i funktionalitet, størrelse og ydeevne.
Nogle terminaler har direkte overraskende sikkerhedshuller, plus de fleste har en helt forskellig sæt af funktioner, fra understøttelse af fanebladgrænseflader til scripts. Selvom vi , er denne artikel en opdatering af det tidligere materiale, der hjælper læserne med at afgøre, hvilken terminal de skal bruge i 2018. I den første halvdel af artiklen sammenlignes funktionerne, mens der i den anden halvdel vurderes ydeevnen.
Her er de terminaler, jeg har gennemgået:
Måske er dette ikke de nyeste versioner, da jeg har begrænset mig til stabile builds på tidspunktet for skrivningen, som jeg kunne installere på Debian 9 eller Fedora 27. Det eneste undtagelse er Alacritty. Det er efterkommer af terminaler med GPU-acceleration og skrevet i et usædvanligt og nyt sprog for denne opgave - Rust. Jeg udelod webterminaler (inklusive, og på ), fordi de indledende tests viste deres ekstremt lave ydeevne.
Unicode-support
Jeg startede mine tests med understøttelse af unicode. Den første test af terminalerne var at vise en tekststreng om unicode fra : «é, Δ, Й, ק, م, ๗, あ, 叶, 葉 og 말». Denne enkle test viser, om terminalen korrekt kan arbejde over hele verden. Terminalen xterm viser ikke det arabiske tegn i standardkonfigurationen:
Som standard bruger xterm den klassiske «fixed» skrifttype, som ifølge , har «betydelig unicode-dækning siden 1997». I denne skrifttype sker der noget, der får symbolet til at vises som en tom ramme, og kun når tekststørrelsen øges til 20+ punkter, begynder symbolet endelig at blive vist korrekt. Men denne «fix» ødelægger visningen af andre unicode-tegn:
Disse skærmbilleder blev taget i Fedora 27, da det gav de bedste resultater sammenlignet med Debian 9, hvor nogle ældre versioner af terminaler (specifikt - mlterm) ikke kunne fungere korrekt med skrifttyper. Heldigvis blev dette rettet i senere versioner.
Nu skal du bemærke visningen af strengen i xterm. Det viser sig, at symbolet Mem og det følgende semitiske tilhører skriftscenarierne RTL (), så teknisk set skal de vises fra højre mod venstre. Webbrowsere, som f.eks. Firefox 57, behandler korrekt den tidligere nævnte streng. En lettere variant af RTL-tekst er ordet «» på hebraisk (). siger følgende:
«Mange computerprogrammer kan ikke korrekt vise tovejstekst. For eksempel består det hebraiske navn «Sara» af tegnene sin (ש) (som vises til højre), derefter resh (ר) og til sidst he (ה) (som skal vises til venstre).»
Mange terminaler består ikke testen: Alacritty, VTE-baserede Gnome og XFCE terminaler, urxvt, st og xterm viser "Sara" i omvendt rækkefølge, som om vi skrev dette navn som "Aras".
Et andet problem med tovejs tekster er, at de skal justeres på en eller anden måde, især når det handler om blanding af RTL og LTR-tekster. RTL-scripts skal starte fra højre side af terminalvinduet, men hvad skal der ske med terminaler, der normalt arbejder med LTR-engelsk? De fleste har ikke nogen særlige mekanismer og venstrejusterer al tekst (inklusive i Konsole). Undtagelsen er pterm og mlterm, som følger standarderne og højrejusterer sådanne strenge.
Beskyttelse mod indsættelse
Den næste kritiske funktion, jeg har identificeret, er beskyttelse mod indsættelse. Selvom det er velkendt, at kommandoer som:
$ curl http://example.com/ | sher push-kommandoer til udførelse af kode, ved få at skjulte kommandoer kan trænge ind i konsollen ved kopiering-indsæt fra en webbrowser, selv efter en grundig inspektion. viser glimrende, hvordan en tilsyneladende harmløs kommando:
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitbliver ved indsættelse fra Horns websted i terminalen til sådan noget ubehageligt:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nDet var en dårlig idé. Don'"'"'t copy code from websites you don'"'"'t trust!
Her'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitHvordan fungerer det? Den skadelige kode er taget ud i en blok , som er flyttet uden for brugerens synsfelt ved hjælp af CSS.
er specifikt designet til at neutralisere sådanne angreb. I denne tilstand indkapsler terminaler den indsatte tekst i et par specielle escape-sekvenser for at informere shellen om oprindelsen af denne tekst. Så shellen får signal om, at den kan ignorere specialtegn, som den indsatte tekst kan indeholde. Alle terminaler, selv den ædle xterm, understøtter denne funktion, men indsættelse i Bracketed-tilstand kræver support fra shellen eller applikationen, der kører på terminalen. For eksempel kræver software, der bruger (den samme Bash), en fil ~/.inputrc:
set enable-bracketed-paste onDesværre viser Horns testsite også, hvordan man kan omgå denne beskyttelse gennem selve tekstformateringen og forhastet afslutte anvendelsen af Bracketed-tilstand. Det fungerer, fordi nogle terminaler filtrerer escape-sekvenser forkert, før de tilføjer deres egne. For eksempel kunne jeg i mine tests ikke afslutte Konsole-testene med korrekt konfiguration. .inputrc fil. Det betyder, at du nemt kan få skader på systemkonfigurationen på grund af en unsupported applikation eller en forkert konfigureret shell. Dette er især farligt, når du logger ind på fjernservere, hvor grundig konfiguration sjældnere forekommer, især hvis du har mange af sådanne fjernmaskiner.
En god løsning på dette problem er en indsætningsbekræftelsespluggin til terminalen urxvt, som simpelthen anmoder om tilladelse, når du indsætter tekst, der indeholder nye linjer. Jeg har ikke fundet en mere sikker løsning på den tekstlige angreb beskrevet af Horn.
Faner og profiler
En populær funktion nu er understøttelse af en grænseflade med faner, som vi definerer som et terminalvindue, der indeholder flere terminaler. For forskellige terminaler adskiller denne funktion sig, og mens traditionelle terminaler som xterm slet ikke understøtter faner, har mere moderne terminaler som Xfce Terminal, GNOME Terminal og Konsole denne funktion. Urxvt understøtter også faner, men kun når der anvendes en pluggin. Men med hensyn til ren fanestøtte er Terminator ubestridt førende: den understøtter ikke blot faner, men kan også placere terminaler i vilkårlig rækkefølge (se billede nedenfor).
En anden funktion ved Terminator er muligheden for at "gruppere" disse faner sammen og sende de samme tastetryk til flere terminaler samtidigt, hvilket giver et groft værktøj til at udføre masseoperationer på flere servere samtidigt. En lignende funktion er også implementeret i Konsole. For at bruge denne funktion i andre terminaler er det nødvendigt at anvende tredjeparts software, som , eller .
Specielt fungerer fanerne godt sammen med profiler: for eksempel kan du have én fane til e-mail, en anden til chat osv. Dette understøttes godt af Konsole-terminalen og GNOME Terminal. Begge tillader hver fane at starte sin egen profil automatisk. Terminator understøtter også profiler, men jeg kunne ikke finde en måde at starte specifikke programmer automatisk, når en bestemt fane åbnes. Andre terminaler har slet ikke begrebet "profil".
Volanger
Det sidste, jeg vil se på i første del af denne artikel, er udseendet af terminalerne. For eksempel understøtter GNOME, Xfce og urxvt gennemsigtighed, men for nylig har de droppet understøttelsen af baggrundsbilleder, hvilket fik nogle brugere til at skifte terminal. . Personligt er jeg glad for den enkle løsning. Xresources, som sætter et grundlæggende farveskema for urxvt. Men ikke-standard farvetemaer kan skabe problemer. For eksempel, med applikationer og , da de allerede bruger deres egne farver.
understøttede ikke farver, og nyere terminaler var ofte begrænset til en 256-farvepalette. For erfarne brugere, der designer deres terminaler med komplekse stilarter, kan dette være en ubehagelig begrænsning. sporer, hvilke terminaler der har understøttelse af "True Color". Mine tests bekræfter, at st, Alacritty og terminaler baseret på VTE understøtter True Color perfekt. Andre terminaler fungerer ikke så godt i denne henseende og viser faktisk ikke engang 256 farver. Nedenfor kan du se forskellen i understøttelse af True Color i terminalerne GNOME, st og xterm, der håndterer denne opgave godt med deres 256-farvepalette, og urxvt, der ikke kun misser testen, men endda viser blinkende symboler i stedet.
Nogle terminaler analyserer også teksten for URL-mønstre for at gøre links klikbare. Dette gælder alle VTE-baserede terminaler, mens urxvt kræver et særligt tilføjelsesmodul, der kan transformere URL-adresser ved klik eller med en genvejstast. Andre terminaler, jeg testede, viser URL-adresser på andre måder.
Endelig er en ny trend inden for terminaler valgfrie scroll-buffere. For eksempel i st er der ingen scroll-buffer; det antages, at brugeren vil bruge en terminal multiplexer som tmux, og .
I Alacritty findes der heller ikke tilbageholdte scroll-buffere, men på grund af det 'store antal feedback' fra brugerne om dette emne. Bortset fra disse undtagelser understøtter hver terminal, jeg har taget et kig på, tilbageholdt scrolling.
Mellemsammenfatning
I del to af materialet (i originalen var der to forskellige artikler, - bem. red.) vil vi sammenligne ydeevne, hukommelsesforbrug og forsinkelse. Men vi ser allerede, at nogle af de betragtede terminaler har alvorlige mangler. For eksempel kan brugere, der regelmæssigt arbejder med RTL-scripts, bemærke mlterm og pterm, da de klarer disse opgaver bedre end de fleste. Konsole har også vist sig at være god. Brugere, der ikke arbejder med RTL-scripts, kan vælge noget andet.
Set fra et sikkerhedsmæssigt perspektiv skiller urxvt sig ud på grund af sin særlige implementering af beskyttelse mod denne slags angreb, som jeg bestemt synes er praktisk. Dem, der leder efter nogle spændende funktioner, bør se på Konsole. Endelig skal det bemærkes, at VTE er et fremragende grundlag for terminaler, der sikrer farveunderstøttelse, genkendelse af URL'er og så videre. Ved første øjekast kan den standardterminal, der leveres med dit yndlingsmiljø, opfylde alle krav, men lad os lade dette spørgsmål stå åbent, indtil vi har undersøgt ydeevnen.
Lad os fortsætte samtalen
Generelt kan ydeevnen ved terminaler synes at være en opfundet problemstilling, men som det viser sig, demonstrerer nogle af dem en overraskende høj forsinkelse for så grundlæggende software. Desuden vil vi se på, hvad der traditionelt kaldes 'hastighed' (faktisk er dette scrolling-hastighed) og terminalens hukommelsesforbrug (med den tanke, at dette i dag ikke er så kritisk som for årtier siden).
Forsinkelse
Efter nøje at have undersøgt terminalernes ydeevne er jeg kommet frem til, at den vigtigste parameter i denne sammenhæng er forsinkelsens størrelse (ping). I min artikel Pavel Fatin har undersøgt forsinkelsen i forskellige tekstredaktører og antydet, at terminaler på dette område kan fungere langsommere end de hurtigste tekstredaktører. Netop denne antydning førte mig til at starte mine egne tests og skrive denne artikel.
Men hvad er forsinkelse, og hvorfor er den så vigtig? I sin artikel definerede Fatin den som «forsinkelsen mellem tryk på en tast og den tilsvarende opdatering af skærmen» og citerede , hvori der står: «Forsinkelsen i visuel feedback på computerens skærm har en vigtig indflydelse på skrivers adfærd og tilfredshed».
Fatin forklarer, at sådan en ping har dybere konsekvenser end blot tilfredshed: «at skrive bliver langsommere, der opstår flere fejl, og muskel- og øjenspænding øges». Med andre ord kan en stor forsinkelse føre til tastefejl samt nedsat kodens kvalitet, da det medfører en ekstra kognitiv belastning for hjernen. Men hvad der er værre, pingen «øver øjenspænding og muskelspænding», hvilket tilsyneladende antyder i fremtiden (tilsyneladende henviser forfatteren til problemer med øjenmusklerne, ryggen, hænderne og selvfølgelig synet — red.) på grund af gentagen belastning.
Nogle af disse effekter er kendte længe, og resultaterne , offentliggjort allerede i 1976 i tidsskriftet Ergonomics, viser, at en forsinkelse på 100 millisekunder «betydeligt forværrer skrivehastigheden». For nylig blev det i brugervejledningen til GNOME indført på 10 millisekunder, og hvis man ser længere frem, så viser, at idealet er 1 millisekund.
Fatin udførte sine tests på tekstredaktører; han skabte et bærbart værktøj kaldet , som jeg brugte til at teste ping i terminalemulatorer. Bemærk, at testen blev udført i simuleringsmodus: i virkeligheden skal vi tage hensyn til indtastningsforsinkelsen (tastatur, USB-controller osv.) og udgangsforsinkelsen (grafikbuffer, skærm). Ifølge Fatin er den typiske konfiguration omkring 20 ms. Med gaming-udstyr kan man opnå en forsinkelse på kun 3 millisekunder. Da vi allerede har så hurtigt udstyr, bør applikationen ikke tilføje sin egen forsinkelse. Fatins mål er at reducere applikationens forsinkelse til 1 millisekund, eller helt undgå forsinkelse i opsætningen. , som i .
Her er resultaterne af mine målinger samt nogle af Fatins resultater for at vise, at mit eksperiment stemmer overens med hans tests:
Det første, der overraskede mig, var den bedre responstid hos ældre programmer som xterm og mlterm. Med en registreringsforsinkelse (2,4 ms) præsterede de bedre end den hurtigste moderne terminal (10,6 ms for st). Ingen moderne terminal kommer under tærsklen på 10 millisekunder. Især opfylder Alacritty ikke kravene til 'den hurtigste af eksisterende terminalemulatorer', selvom dets resultater er blevet forbedret siden den første test i 2017. Faktisk er forfatterne af projektet og arbejder på at forbedre ydeevnen. Det er også vigtigt at bemærke, at Vim, der bruger GTK3, er væsentligt langsommere end sin GTK2-modpart. Dette tyder på, at GTK3 introducerer ekstra forsinkelse, hvilket også påvirker andre terminaler, der bruger det (Terminator, Xfce4 Terminal og GNOME Terminal).
Dog kan forskellene være usynlige for øjet. Som Fatin forklarer: 'Det er ikke nødvendigt at være klar over forsinkelsen for at den påvirker dig'. Fatin advarer også om standardafvigelsen: 'Enhver variation i varigheden af forsinkelsen (rysten) skaber en ekstra belastning på grund af deres uforudsigelighed'.
Grafikken ovenfor er opnået på ren Debian 9 (stretch) med . Dette miljø giver de bedste resultater i latensmålinger. Som det viser sig, tilføjer GNOME en ekstra ping på 20 ms til alle målinger. En mulig forklaring på dette er tilstedeværelsen af programmer med synkron behandling af indgangshændelser. Fatin giver et eksempel på en sådan situation , som tilføjer forsinkelse ved at behandle alle input-hændelser synkront. Som standard leveres GNOME også med vinduesleder , som skaber et ekstra niveau af buffering, hvilket påvirker ping og tilføjer mindst 8 millisekunders forsinkelse.
Rullemulighed
Den næste test er den traditionelle kontrol af "hastighed" eller "båndbredde", der måler hvor hurtigt terminalen kan rulle en side, der viser en stor mængde tekst på skærmen. Testens mekanik varierer; den oprindelige test bestod i at generere den samme tekststreng ved hjælp af kommandoen seq. Andre tests inkluderer Thomas E. Dickes test (som understøtter xterm), hvorved der gentagne gange . I en anden terminalpræstationsvurdering bruger en række tilfældige bytes i base32-kodning, som vises i terminalen ved hjælp af cat. Luu anser en sådan test for "så nytteløs som en benchmark kan være" og foreslår at bruge terminalens respons som hovedmåleparameter i stedet. Dicke beskriver også sin test som vildledende. Ikke desto mindre anerkender begge forfattere, at båndbredden i terminalvinduet kan være et problem. Luu opdagede lag i Emacs Eshell, når der vises store filer, og Dicke optimerede terminalen for at eliminere den visuelle forsinkelse i xterm. Derfor er der stadig en vis relevans i denne test, men da renderingsprocessen varierer betydeligt mellem terminaler, kan den også bruges som et testkomponent til at evaluere andre parametre.
Her ser vi, at rxvt og st klarer sig bedre end konkurrenterne, efterfulgt af det meget nyere Alacritty, der er udviklet med fokus på hastighed. Dernæst kommer Xfce (VTE-familien) og Konsole, som næsten fungerer dobbelt så hurtigt. Til sidst er xterm, som er fem gange langsommere end rxvt. Under testen rystede xterm også kraftigt, og det var svært at se den passerende tekst, selv når det var den samme linje. Konsole viste sig at være hurtig, men den 'snyder' nogle gange: Skærmen hang ind imellem, hvilket viste teksten delvist eller slet ikke. Andre terminaler viste linjerne klart, herunder st, Alacritty og rxvt.
Diki forklarer, at forskellene i ydeevne skyldes designet af rullebufre i forskellige terminaler. Især beskylder han rxvt og andre terminaler for ikke at 'følge de almindelige regler':
«I modsætning til xterm, forsøgte rxvt ikke at vise alle opdateringer. Hvis den falder bagud, vil den opgive nogle opdateringer for at indhente det forsømte. Dette havde større indflydelse på den tilsyneladende rullehastighed end på organiseringen af intern hukommelse. En ulempe var, at ASCII-animationen var lidt unøjagtig».
For at rette op på denne tilsyneladende langsomhed i xterm, foreslår Diki at bruge ressourcen , som gør det muligt for xterm at falde noget screen updates, så den ikke falder bagud i strømmen. Mine tests bekræfter, at fastScroll forbedrer ydeevnen og bringer xterm op på niveau med rxvt. Dette er dog en temmelig grov løsning, som Diki selv forklarer: «Nogle gange virker xterm – ligesom konsole – til at stoppe, da den venter på et nyt sæt skærmopdateringer, efter at nogle af dem er blevet fjernet». I denne sammenhæng ser det ud til, at andre terminaler har fundet den bedste kompromis mellem hastighed og skærmintegritet.
Ressourceforbrug
Uanset hvor praktisk det er at overveje rullehastighed som en indikator for ydeevne, gør denne test det muligt at simulere belastningen på terminalerne, hvilket igen giver os mulighed for at måle andre parametre såsom hukommelse eller diskbrug. Metrikkerne blev opnået ved at køre den angivne test seq under overvågning af Python-processen. Den indsamlede data fra tællerne for ru_maxrss, summen af ru_oublock og ru_inblock og en simpel tidsmåler.
I denne test indtager ST førstepladsen med det laveste gennemsnitlige hukommelsesforbrug på 8 MB, hvilket ikke er overraskende, når hovedideen bag projektet er enkelhed. Mlterm, xterm og rxvt bruger lidt mere - omkring 12 MB. En anden bemærkelsesværdig præstation kommer fra Alacritty, som kræver 30 MB for at fungere. Derfter følger terminalerne i VTE-familien med forbrug på mellem 40 og 60 MB, hvilket er ret meget. Denne forbrug kan forklares med, at disse terminaler bruger højere niveau biblioteker, såsom GTK. Konsole kommer sidst med et kolossalt forbrug på 65 MB hukommelse under testene, selvom dette kan retfærdiggøres med dets ret brede funktionssæt.
Sammenlignet med de tidligere resultater, der blev opnået for ti år siden, er alle programmer blevet betydeligt mere hukommelseskrævende. Tidligere krævede Xterm 4 MB, og nu kræver det 15 MB bare for at starte. Et tilsvarende forbrug er også set hos rxvt, som nu kræver 16 MB fra start. Xfce-terminalen optager 34 MB, hvilket er tre gange mere end før, mens GNOME Terminal kun kræver 20 MB. Selvfølgelig blev alle tidligere test udført på en 32-bit arkitektur. På LCA 2012, Rasty Russell. , hvilket der er mange dybere årsager til, som kan forklare stigningen i hukommelsesforbruget. Alt dette til trods lever vi nu i en tid, hvor vi har hele gigabyte af hukommelse, så vi klarer os på en eller anden måde.
Ikke desto mindre kan jeg ikke slippe af med følelsen af, at det at tildele mere hukommelse til sådan en grundlæggende software som terminalen er en spild af ressourcer. Disse programmer bør være de mindste blandt de mindste og være i stand til at køre på enhver 'æske', selv en skoboks, hvis vi nogensinde kommer dertil, hvor de skal udstyres med Linux-systemer (og du ved, at det vil ske). Men med disse tal vil hukommelsesforbruget i fremtiden blive et problem i ethvert miljø ved kørsel af flere terminaler, undtagen i tilfælde hvor der bruges de letteste og mest begrænsede versioner. For at kompensere for dette har GNOME Terminal, Konsole, urxvt, Terminator og Xfce Terminal daemon-tilstand, som tillader styring af flere terminaler gennem én proces, hvilket begrænser deres hukommelsesforbrug.
I løbet af mine tests kom jeg til et andet uventet resultat vedrørende disk læsning-skrivning: Jeg forventede overhovedet ikke at se noget her, men det viste sig, at nogle terminaler skriver de mest omfattende data til disk. Så, VTE-biblioteket holder faktisk en scroll-buffer på disken (denne funktion , og det sker stadig). Men i modsætning til de gamle implementeringer, er disse data nu i det mindste krypteret med AES256 GCM (). Men der opstår et rimeligt spørgsmål: Hvad er så specielt ved VTE-biblioteket, at det kræver en så usædvanlig tilgang til implementeringen…
Konklusion
I den første del af artiklen opdagede vi, at terminaler baseret på VTE har et godt udvalg af funktioner, men nu ser vi, at dette er relateret til nogle omkostninger for at sikre deres ydeevne. I øjeblikket er hukommelse ikke et problem, fordi alle VTE-terminaler kan styres via en daemon-proces, der begrænser deres appetit. Alligevel kan gamle systemer, der har fysiske begrænsninger i mængden af RAM og kernens buffer, stadig have brug for tidligere versioner af terminalerne, da de forbruger betydeligt færre ressourcer. Selvom VTE-terminalerne har vist sig godt i tests af båndbredde (scrolling), er deres forsinkelse i visningen af data på skærmen højere end den fastsatte grænse i brugervejledningen til GNOME. Sandsynligvis bør udviklerne af VTE tage dette i betragtning. Når man overvejer, at selv for nye Linux-brugere er mødet med terminalen uundgåeligt, kan de gøre den mere brugervenlig. For erfarne nørder kan overgangen fra standardterminalen endda betyde en reduktion i belastningen på synet og muligheden for at undgå professionelle skader og sygdomme i fremtiden på grund af lange arbejds-sessioner. Desværre fører kun de gamle xterm og mlterm os til den magiske ping-grænse på 10 millisekunder, hvilket for mange er uacceptabelt.
Målingerne viste også, at udviklingen af grafiske miljøer i Linux har fået udviklere til at indgå et par kompromisser. Nogle brugere bør overveje at se på almindelige vinduesforvaltere, da de giver en betydelig reduktion i ping. Desværre var det ikke muligt at måle latensen for Wayland: programmet Typometer, som jeg brugte, blev skabt for netop det, som Wayland sigter mod at forhindre - overvågning af andre vinduer. Jeg håber, at Waylands sammensætning præsterer bedre end X.org, og jeg håber også, at nogen i fremtiden finder en måde at vurdere latenstiden i dette miljø.
Kilde: habr.com
