Λίγα λόγια από το μεταφραστικό μας γραφείο: συνήθως όλοι προσπαθούν να μεταφράσουν το πιο πρόσφατο υλικό και δημοσιεύσεις, και εμείς δεν αποτελούμε εξαίρεση. Αλλά τα τερματικά δεν είναι κάτι που ενημερώνεται μία φορά την εβδομάδα. Επομένως, μεταφράσαμε για εσάς ένα άρθρο του Antoine Beaupré, που δημοσιεύτηκε την άνοιξη του 2018: παρά τη σημαντική «ηλικία» του με τα σύγχρονα πρότυπα, κατά τη γνώμη μας, το υλικό δεν έχει χάσει καθόλου τη συνάφειά του. Επιπλέον, αυτή ήταν αρχικά μια σειρά από δύο άρθρα, αλλά αποφασίσαμε να τα συνδυάσουμε σε μια μεγάλη ανάρτηση.
Τα τερματικά έχουν ιδιαίτερη θέση στην ιστορία των υπολογιστών, αλλά τις τελευταίες δεκαετίες αναγκάστηκαν να επιβιώσουν παράλληλα με τη γραμμή εντολών καθώς οι γραφικές διεπαφές γίνονται πανταχού παρούσες. αντικατέστησαν το δικό τους , τα οποία, με τη σειρά τους, ήταν μια τροποποίηση συστημάτων που βασίστηκαν σε διάτρητες κάρτες και διακόπτες εναλλαγής. Οι σύγχρονες διανομές συνοδεύονται από μια ποικιλία τερματικών εξομοιωτών όλων των σχημάτων και χρωμάτων. Και ενώ πολλοί είναι ικανοποιημένοι με το τυπικό τερματικό που παρέχεται από το περιβάλλον εργασίας τους, ορισμένοι χρησιμοποιούν περήφανα εξωτικό λογισμικό για να εκτελέσουν το αγαπημένο τους πρόγραμμα επεξεργασίας κελύφους ή κειμένου. Όμως, όπως θα δούμε από αυτό το άρθρο, δεν δημιουργήθηκαν όλα τα τερματικά με την ίδια εικόνα: διαφέρουν πολύ ως προς τη λειτουργικότητα, το μέγεθος και την απόδοση.
Ορισμένα τερματικά έχουν εντελώς εκπληκτικές οπές ασφαλείας, συν τα περισσότερα έχουν ένα εντελώς διαφορετικό σύνολο λειτουργιών, από υποστήριξη για διεπαφή με καρτέλες έως δέσμες ενεργειών. Αν και εμείς , αυτό το άρθρο είναι μια ενημέρωση του προηγούμενου υλικού που θα βοηθήσει τους αναγνώστες να καθορίσουν ποιο τερματικό θα χρησιμοποιήσουν το 2018. Το πρώτο μισό του άρθρου συγκρίνει χαρακτηριστικά και το δεύτερο μισό αξιολογεί την απόδοση.
Εδώ είναι τα τερματικά που εξέτασα:
Αυτές μπορεί να μην είναι οι πιο πρόσφατες εκδόσεις, καθώς περιορίστηκα σε σταθερές εκδόσεις τη στιγμή της συγγραφής, τις οποίες μπόρεσα να κυκλοφορήσω στο Debian 9 ή στο Fedora 27. Η μόνη εξαίρεση είναι το Alacritty. Είναι απόγονος τερματικών με επιτάχυνση GPU και είναι γραμμένο σε μια ασυνήθιστη και νέα γλώσσα για αυτήν την εργασία - Rust. Εξαίρεσα τερματικά ιστού από την κριτική μου (συμπεριλαμβανομένων αυτών που βρίσκονται στο ), επειδή οι προκαταρκτικές δοκιμές έδειξαν εξαιρετικά κακή απόδοση.
Υποστήριξη Unicode
Ξεκίνησα τις δοκιμές μου με υποστήριξη Unicode. Η πρώτη δοκιμή των τερματικών ήταν να εμφανιστεί η συμβολοσειρά Unicode από : "é, Δ, И, ק, م, ๗, あ, 叶, 葉 και 말." Αυτή η απλή δοκιμή δείχνει εάν το τερματικό μπορεί να λειτουργήσει σωστά παγκοσμίως. Το τερματικό xterm δεν εμφανίζει αραβικό χαρακτήρα στην προεπιλεγμένη διαμόρφωση:
Από προεπιλογή, το xterm χρησιμοποιεί την κλασική «σταθερή» γραμματοσειρά, η οποία, σύμφωνα με , έχει «ουσιαστική κάλυψη Unicode από το 1997». Υπάρχει κάτι που συμβαίνει σε αυτήν τη γραμματοσειρά που κάνει τον χαρακτήρα να εμφανίζεται ως κενό πλαίσιο και μόνο όταν η γραμματοσειρά κειμένου αυξηθεί σε 20+ σημεία, ο χαρακτήρας αρχίζει τελικά να εμφανίζεται σωστά. Ωστόσο, αυτή η "διόρθωση" σπάει την εμφάνιση άλλων χαρακτήρων Unicode:
Αυτά τα στιγμιότυπα οθόνης τραβήχτηκαν στο Fedora 27, καθώς έδωσε καλύτερα αποτελέσματα από το Debian 9, όπου ορισμένες παλαιότερες εκδόσεις τερματικών (συγκεκριμένα το mlterm) δεν μπορούσαν να χειριστούν σωστά τις γραμματοσειρές. Ευτυχώς αυτό διορθώθηκε σε μεταγενέστερες εκδόσεις.
Τώρα παρατηρήστε πώς εμφανίζεται η γραμμή στο xterm. Αποδεικνύεται ότι το σύμβολο Mem και το ακόλουθο Σημιτικό ανατρέξτε στα σενάρια στυλ RTL (), επομένως τεχνικά θα πρέπει να εμφανίζονται από δεξιά προς τα αριστερά. Τα προγράμματα περιήγησης Ιστού όπως το Firefox 57 χειρίζονται σωστά την παραπάνω γραμμή. Μια απλούστερη έκδοση του κειμένου RTL είναι η λέξη ""στα Εβραϊκά (). λέει τα εξής:
«Πολλά προγράμματα υπολογιστή δεν μπορούν να εμφανίσουν σωστά αμφίδρομο κείμενο. Για παράδειγμα, το εβραϊκό όνομα "Sarah" αποτελείται από τους χαρακτήρες sin (ש) (που εμφανίζεται στα δεξιά), μετά resh (ר) και τέλος he (ה) (που πρέπει να εμφανίζεται στα αριστερά)."
Πολλά τερματικά αποτυγχάνουν σε αυτό το τεστ: τερματικά Alacritty, Gnome και XFCE που προέρχονται από VTE, urxvt, st και xterm εμφανίζουν το "Sara" με αντίστροφη σειρά, σαν να είχαμε γράψει το όνομα ως "Aras".
Ένα άλλο πρόβλημα με τα αμφίδρομα κείμενα είναι ότι πρέπει να ευθυγραμμιστούν με κάποιο τρόπο, ειδικά όταν πρόκειται για τη μίξη κειμένων RTL και LTR. Τα σενάρια RTL θα πρέπει να εκτελούνται από τη δεξιά πλευρά του παραθύρου του τερματικού, αλλά τι πρέπει να συμβεί για τερματικά που έχουν προεπιλογή LTR English; Τα περισσότερα από αυτά δεν διαθέτουν ειδικούς μηχανισμούς και ευθυγραμμίζουν όλο το κείμενο προς τα αριστερά (συμπεριλαμβανομένου του Konsole). Οι εξαιρέσεις είναι το pterm και το mlterm, τα οποία τηρούν τα πρότυπα και ευθυγραμμίζουν αυτές τις γραμμές δεξιά.
Προστασία εισαγωγής
Το επόμενο κρίσιμο χαρακτηριστικό που έχω εντοπίσει είναι η προστασία κατά της εισαγωγής. Αν και είναι ευρέως γνωστό ότι ξόρκια όπως:
$ curl http://example.com/ | shείναι εντολές push εκτέλεσης κώδικα, λίγοι άνθρωποι γνωρίζουν ότι οι κρυφές εντολές μπορούν να εισχωρήσουν κρυφά στην κονσόλα κατά την αντιγραφή και επικόλληση από ένα πρόγραμμα περιήγησης ιστού, ακόμη και μετά από προσεκτική επιθεώρηση. δείχνει έξοχα πόσο αβλαβής είναι η εντολή:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gitμετατρέπεται σε τέτοια ενόχληση όταν επικολληθεί από τον ιστότοπο του Horn στο τερματικό:
git clone /dev/null;
clear;
echo -n "Hello ";
whoami|tr -d 'n';
echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust!
Here'"'"'s the first line of your /etc/passwd: ';
head -n1 /etc/passwd
git clone git://git.kernel.org/pub/scm/utils/kup/kup.gitΠως δουλεύει? Ο κακόβουλος κώδικας περιλαμβάνεται στο μπλοκ , το οποίο απομακρύνεται από την προβολή του χρήστη χρησιμοποιώντας CSS.
έχει σχεδιαστεί σαφώς για να εξουδετερώνει τέτοιες επιθέσεις. Σε αυτήν τη λειτουργία, τα τερματικά περικλείουν το επικολλημένο κείμενο σε ένα ζεύγος ειδικών ακολουθιών διαφυγής για να ενημερώσουν το κέλυφος για την προέλευση του κειμένου. Αυτό λέει στο κέλυφος ότι μπορεί να αγνοήσει ειδικούς χαρακτήρες που μπορεί να περιέχει το επικολλημένο κείμενο. Όλα τα τερματικά πίσω στο σεβαστό xterm υποστηρίζουν αυτήν τη δυνατότητα, αλλά η επικόλληση σε λειτουργία Bracketed απαιτεί υποστήριξη από το κέλυφος ή την εφαρμογή που εκτελείται στο τερματικό. Για παράδειγμα, χρήση λογισμικού (ίδιο Bash), χρειάζεται αρχείο ~/.inputrc:
set enable-bracketed-paste onΔυστυχώς, ο ιστότοπος δοκιμών του Horn δείχνει επίσης πώς να παρακάμψετε αυτήν την προστασία μέσω της ίδιας της μορφοποίησης κειμένου και να καταλήξετε πρόωρα να εφαρμόσετε τη λειτουργία Bracketed σε αυτό. Αυτό λειτουργεί επειδή ορισμένα τερματικά δεν φιλτράρουν σωστά τις ακολουθίες διαφυγής πριν προσθέσουν τις δικές τους. Για παράδειγμα, στο δικό μου δεν μπόρεσα ποτέ να ολοκληρώσω με επιτυχία τις δοκιμές της Konsole ακόμα και με τη σωστή διαμόρφωση .inputrc αρχείο. Αυτό σημαίνει ότι μπορείτε εύκολα να καταστρέψετε τη διαμόρφωση του συστήματός σας λόγω μιας μη υποστηριζόμενης εφαρμογής ή ενός εσφαλμένα διαμορφωμένου κελύφους. Αυτό είναι ιδιαίτερα επικίνδυνο όταν συνδέεστε σε απομακρυσμένους διακομιστές, όπου η προσεκτική εργασία ρύθμισης παραμέτρων είναι λιγότερο συχνή, ειδικά εάν έχετε πολλά τέτοια απομακρυσμένα μηχανήματα.
Μια καλή λύση σε αυτό το πρόβλημα είναι η προσθήκη επιβεβαίωσης επικόλλησης για το τερματικό urxvt, το οποίο απλώς ζητά άδεια για την εισαγωγή οποιουδήποτε κειμένου που περιέχει νέες γραμμές. Δεν βρήκα πιο ασφαλή επιλογή για την επίθεση κειμένου που περιγράφει ο Χορν.
Καρτέλες και προφίλ
Ένα δημοφιλές χαρακτηριστικό τώρα είναι η υποστήριξη για μια διεπαφή με καρτέλες, την οποία θα ορίσουμε ως ένα παράθυρο τερματικού που περιέχει πολλά ακόμα τερματικά. Αυτή η λειτουργία διαφέρει για διαφορετικά τερματικά και παρόλο που τα παραδοσιακά τερματικά xterm δεν υποστηρίζουν καθόλου καρτέλες, πιο σύγχρονες ενσαρκώσεις τερματικών όπως το Xfce Terminal, το GNOME Terminal και η Konsole έχουν αυτήν τη λειτουργία. Το Urxvt υποστηρίζει επίσης καρτέλες, αλλά μόνο εάν χρησιμοποιείτε πρόσθετο. Αλλά όσον αφορά την ίδια την υποστήριξη καρτελών, το Terminator είναι ο αδιαμφισβήτητος ηγέτης: όχι μόνο υποστηρίζει καρτέλες, αλλά μπορεί επίσης να τακτοποιήσει τερματικά με οποιαδήποτε σειρά (δείτε την εικόνα παρακάτω).
Ένα άλλο χαρακτηριστικό του Terminator είναι η δυνατότητα "ομαδοποίησης" αυτών των καρτελών και αποστολής των ίδιων πλήκτρων σε πολλαπλά τερματικά ταυτόχρονα, παρέχοντας ένα ακατέργαστο εργαλείο για την εκτέλεση μαζικών λειτουργιών σε πολλούς διακομιστές ταυτόχρονα. Ένα παρόμοιο χαρακτηριστικό εφαρμόζεται επίσης στο Konsole. Για να χρησιμοποιήσετε αυτήν τη δυνατότητα σε άλλα τερματικά, πρέπει να χρησιμοποιήσετε λογισμικό τρίτων, όπως π.χ , ή .
Οι καρτέλες λειτουργούν ιδιαίτερα καλά όταν συνδυάζονται με προφίλ: για παράδειγμα, μπορείτε να έχετε μια καρτέλα για email, μια άλλη για συνομιλία και ούτω καθεξής. Αυτό υποστηρίζεται καλά από το Konsole Terminal και το GNOME Terminal. Και οι δύο επιτρέπουν σε κάθε καρτέλα να εκκινεί αυτόματα το δικό της προφίλ. Το Terminator υποστηρίζει επίσης προφίλ, αλλά δεν μπόρεσα να βρω τρόπο να εκκινήσω αυτόματα ορισμένα προγράμματα όταν ανοίγετε μια συγκεκριμένη καρτέλα. Άλλα τερματικά δεν έχουν καθόλου την έννοια του "προφίλ".
Βολάν
Το τελευταίο πράγμα που θα καλύψω στο πρώτο μέρος αυτού του άρθρου είναι η εμφάνιση των τερματικών. Για παράδειγμα, το GNOME, το Xfce και το urxvt υποστηρίζουν τη διαφάνεια, αλλά πρόσφατα διέκοψαν την υποστήριξη για εικόνες φόντου, αναγκάζοντας ορισμένους χρήστες να μεταβούν στο τερματικό . Προσωπικά, είμαι ευχαριστημένος με αυτό και είναι απλό Πηγές, το οποίο ορίζει το βασικό σύνολο χρωμάτων φόντου για το urxvt. Ωστόσο, τα μη τυποποιημένα έγχρωμα θέματα μπορούν επίσης να δημιουργήσουν προβλήματα. Για παράδειγμα, με εφαρμογές и , αφού ήδη χρησιμοποιούν τα δικά τους χρώματα.
δεν υποστήριζε χρώματα και τα νέα περιορίζονταν συχνά σε μια παλέτα 256 χρωμάτων. Για προχωρημένους χρήστες που διαμορφώνουν τα τερματικά τους, τα μηνύματα κελύφους ή οι γραμμές κατάστασης με περίπλοκους τρόπους μπορεί να είναι ένας ενοχλητικός περιορισμός. παρακολουθεί ποια τερματικά έχουν υποστήριξη "True Color". Οι δοκιμές μου επιβεβαιώνουν ότι τα τερματικά st, Alacritty και VTE υποστηρίζουν τέλεια το True Color. Άλλα τερματικά δεν τα πηγαίνουν πολύ καλά από αυτή την άποψη και, στην πραγματικότητα, δεν εμφανίζουν καν 256 χρώματα. Παρακάτω μπορείτε να δείτε τη διαφορά μεταξύ της υποστήριξης True Color στα τερματικά GNOME, st και xterm, τα οποία κάνουν καλή δουλειά με την παλέτα χρωμάτων τους 256, και urxvt, που όχι μόνο αποτυγχάνει στη δοκιμή, αλλά δείχνει ακόμη και μερικούς χαρακτήρες που αναβοσβήνουν αντί αυτών.
Ορισμένα τερματικά αναλύουν επίσης κείμενο για μοτίβα URL για να κάνουν τους συνδέσμους με δυνατότητα κλικ. Αυτό ισχύει για όλα τα τερματικά που προέρχονται από VTE, ενώ το urxvt απαιτεί μια ειδική προσθήκη που θα μετασχηματίζει τις διευθύνσεις URL με ένα κλικ ή χρησιμοποιώντας μια συντόμευση πληκτρολογίου. Άλλα τερματικά που έχω δοκιμάσει τα URL εμφάνισης με άλλους τρόπους.
Τέλος, μια νέα τάση στα τερματικά είναι η προαιρετική δυνατότητα του scroll buffer. Για παράδειγμα, το st δεν έχει buffer κύλισης. Υποτίθεται ότι ο χρήστης θα χρησιμοποιήσει έναν τερματικό πολυπλέκτη όπως το tmux και .
Το Alacritty στερείται επίσης buffer backscroll, αλλά την υποστήριξή του λόγω "εκτεταμένων σχολίων" σχετικά με αυτό το θέμα από τους χρήστες. Εκτός από αυτές τις εκκινήσεις, κάθε τερματικό που έχω δοκιμάσει και που μπόρεσα να βρω υποστηρίζει την αντίστροφη κύλιση.
Υποσύνολα
Στο δεύτερο μέρος του υλικού (στο πρωτότυπο αυτά ήταν δύο διαφορετικά άρθρα - περίπου. λωρίδα) θα συγκρίνουμε την απόδοση, τη χρήση μνήμης και την καθυστέρηση. Όμως μπορούμε ήδη να δούμε ότι ορισμένα από τα εν λόγω τερματικά έχουν σοβαρές ελλείψεις. Για παράδειγμα, οι χρήστες που εργάζονται τακτικά με σενάρια RTL μπορεί να θέλουν να εξετάσουν το mlterm και το pterm, καθώς χειρίζονται καλύτερα παρόμοιες εργασίες από άλλες. Η Konsole είχε επίσης καλή απόδοση. Οι χρήστες που δεν λειτουργούν με σενάρια RTL μπορούν να επιλέξουν κάτι άλλο.
Όσον αφορά την προστασία από την εισαγωγή κακόβουλου κώδικα, το urxvt ξεχωρίζει λόγω της ειδικής εφαρμογής προστασίας έναντι αυτού του τύπου επίθεσης, κάτι που μου φαίνεται σίγουρα βολικό. Για όσους αναζητούν μερικές καμπάνες και σφυρίχτρες, αξίζει να το δείτε στο Konsole. Τέλος, αξίζει να σημειωθεί ότι το VTE είναι μια εξαιρετική βάση για τερματικά, η οποία εγγυάται υποστήριξη χρώματος, αναγνώριση URL κ.λπ. Με την πρώτη ματιά, το προεπιλεγμένο τερματικό που συνοδεύει το αγαπημένο σας περιβάλλον μπορεί να πληροί όλες τις απαιτήσεις, αλλά ας αφήσουμε αυτήν την ερώτηση ανοιχτή μέχρι να καταλάβουμε την απόδοση.
Συνεχίζουμε την κουβέντα
Γενικά, η απόδοση των τερματικών από μόνη της μπορεί να φαίνεται σαν ένα τραβηγμένο πρόβλημα, αλλά όπως αποδεικνύεται, μερικά από αυτά παρουσιάζουν εκπληκτικά υψηλή καθυστέρηση για λογισμικό τέτοιου θεμελιώδους τύπου. Επίσης, στη συνέχεια θα εξετάσουμε αυτό που παραδοσιακά ονομάζεται «ταχύτητα» (στην πραγματικότητα, αυτή είναι η ταχύτητα κύλισης) και η κατανάλωση μνήμης του τερματικού (με την προειδοποίηση ότι αυτό δεν είναι τόσο κρίσιμο σήμερα όσο πριν από δεκαετίες).
Καθυστέρηση
Μετά από ενδελεχή μελέτη της απόδοσης του τερματικού, κατέληξα στο συμπέρασμα ότι η πιο σημαντική παράμετρος από αυτή την άποψη είναι η καθυστέρηση (ping). Στο άρθρο του Ο Pavel Fatin εξέτασε τον λανθάνοντα χρόνο διαφόρων προγραμμάτων επεξεργασίας κειμένου και υπαινίχθηκε ότι τα τερματικά από αυτή την άποψη μπορεί να είναι πιο αργά από τα πιο γρήγορα προγράμματα επεξεργασίας κειμένου. Ήταν αυτός ο υπαινιγμός που με οδήγησε τελικά να εκτελέσω τις δικές μου δοκιμές και να γράψω αυτό το άρθρο.
Τι είναι όμως η καθυστέρηση και γιατί είναι τόσο σημαντική; Στο άρθρο του, ο Fatin το όρισε ως «την καθυστέρηση ανάμεσα στο πάτημα ενός πλήκτρου και την αντίστοιχη ενημέρωση οθόνης» και παρέθεσε , το οποίο αναφέρει: «Η καθυστέρηση στην οπτική ανάδραση σε μια οθόνη υπολογιστή έχει σημαντικό αντίκτυπο στη συμπεριφορά και την ικανοποίηση της δακτυλογράφου».
Ο Fatin εξηγεί ότι αυτό το ping έχει βαθύτερες συνέπειες από την απλή ικανοποίηση: «η πληκτρολόγηση γίνεται πιο αργή, συμβαίνουν περισσότερα λάθη και η ένταση των ματιών και των μυών αυξάνεται». Με άλλα λόγια, μια μεγάλη καθυστέρηση μπορεί να οδηγήσει σε τυπογραφικά λάθη και επίσης χαμηλότερη ποιότητα κώδικα, καθώς οδηγεί σε επιπλέον γνωστικό φορτίο στον εγκέφαλο. Αλλά το χειρότερο είναι ότι το ping «αυξάνει την καταπόνηση των ματιών και των μυών», κάτι που φαίνεται να σημαίνει στο μέλλον (Προφανώς, ο συγγραφέας εννοεί προβλήματα με τους μύες των ματιών, της πλάτης, των χεριών και, φυσικά, της όρασης - περίπου. λωρίδα) λόγω επαναλαμβανόμενου στρες.
Μερικές από αυτές τις επιπτώσεις είναι γνωστές εδώ και πολύ καιρό, και τα αποτελέσματα , που δημοσιεύτηκε το 1976 στο περιοδικό Ergonomics, ανέφερε ότι μια καθυστέρηση 100 χιλιοστών του δευτερολέπτου "βλάπτει σημαντικά την ταχύτητα πληκτρολόγησης". Πιο πρόσφατα, παρουσιάστηκε ο Οδηγός χρήσης του GNOME σε 10 χιλιοστά του δευτερολέπτου, και αν προχωρήσετε περισσότερο, τότε δείχνει ότι το 1 χιλιοστό του δευτερολέπτου είναι ιδανικό.
Ο Fatin πραγματοποίησε τις δοκιμές του σε συντάκτες κειμένου. δημιούργησε ένα φορητό όργανο που ονομάζεται , το οποίο χρησιμοποίησα για να δοκιμάσω το ping σε εξομοιωτές τερματικού. Λάβετε υπόψη ότι η δοκιμή διεξήχθη σε λειτουργία προσομοίωσης: στην πραγματικότητα, πρέπει να λάβουμε υπόψη τόσο την καθυστέρηση εισόδου (πληκτρολόγιο, ελεγκτής USB, κ.λπ.) όσο και την έξοδο (buffer κάρτας βίντεο, οθόνη). Σύμφωνα με τον Fatin, σε τυπικές διαμορφώσεις είναι περίπου 20 ms. Εάν διαθέτετε εξοπλισμό παιχνιδιών, μπορείτε να επιτύχετε αυτόν τον αριθμό σε μόλις 3 χιλιοστά του δευτερολέπτου. Δεδομένου ότι έχουμε ήδη τόσο γρήγορο υλικό, η εφαρμογή δεν χρειάζεται να προσθέσει τη δική της καθυστέρηση. Ο στόχος του Fatin είναι να φέρει τον λανθάνοντα χρόνο εφαρμογής στο 1 χιλιοστό του δευτερολέπτου ή ακόμη και να επιτύχει κλήση χωρίς , πώς μέσα .
Εδώ είναι τα αποτελέσματα των μετρήσεών μου, καθώς και μερικά από τα αποτελέσματα του Fatin, για να δείξω ότι το πείραμά μου συμφωνεί με τις δοκιμές του:
Το πρώτο πράγμα που μου έκανε εντύπωση ήταν ο καλύτερος χρόνος απόκρισης παλαιότερων προγραμμάτων όπως το xterm και το mlterm. Με τον χειρότερο λανθάνοντα χρόνο εγγραφής (2,4 ms), απέδωσαν καλύτερα από το πιο γρήγορο σύγχρονο τερματικό (10,6 ms για το st). Κανένα σύγχρονο τερματικό δεν πέφτει κάτω από το όριο των 10 χιλιοστών του δευτερολέπτου. Συγκεκριμένα, το Alacritty αποτυγχάνει να ανταποκριθεί στον ισχυρισμό του "γρηγορότερου διαθέσιμου εξομοιωτή τερματικού", αν και οι βαθμολογίες του έχουν βελτιωθεί από την πρώτη του αξιολόγηση το 2017. Πράγματι, οι συντάκτες του έργου και εργάζονται για τη βελτίωση της οθόνης. Θα πρέπει επίσης να σημειωθεί ότι το Vim που χρησιμοποιεί το GTK3 είναι μια τάξη μεγέθους πιο αργό από το αντίστοιχο GTK2. Από αυτό μπορούμε να συμπεράνουμε ότι το GTK3 δημιουργεί πρόσθετο λανθάνον χρόνο και αυτό αντικατοπτρίζεται σε όλα τα άλλα τερματικά που το χρησιμοποιούν (Terminator, Xfce4 Terminal και GNOME Terminal).
Ωστόσο, οι διαφορές μπορεί να μην είναι αισθητές στο μάτι. Όπως εξηγεί ο Fatin, «δεν χρειάζεται να γνωρίζετε την καθυστέρηση για να έχει επίδραση πάνω σας». Ο Fatin προειδοποιεί επίσης για την τυπική απόκλιση: «οποιεσδήποτε διαταραχές στην λανθάνουσα κατάσταση (jitter) δημιουργούν πρόσθετο άγχος λόγω της απρόβλεπτης λειτουργίας τους».
Το παραπάνω γράφημα λαμβάνεται σε καθαρό Debian 9 (stretch) με . Αυτό το περιβάλλον παράγει τα καλύτερα αποτελέσματα σε δοκιμές καθυστέρησης. Όπως αποδεικνύεται, το GNOME δημιουργεί ένα επιπλέον ping 20 ms για όλες τις μετρήσεις. Μια πιθανή εξήγηση για αυτό είναι η παρουσία προγραμμάτων με σύγχρονη επεξεργασία των γεγονότων εισόδου. Ο Φατίν δίνει ένα παράδειγμα για μια τέτοια περίπτωση , το οποίο προσθέτει μια καθυστέρηση επεξεργάζοντας όλα τα συμβάντα εισαγωγής συγχρονισμένα. Από προεπιλογή, το GNOME συνοδεύεται επίσης από έναν διαχειριστή παραθύρων , το οποίο δημιουργεί ένα πρόσθετο στρώμα προσωρινής αποθήκευσης, το οποίο επηρεάζει το ping και προσθέτει τουλάχιστον 8 χιλιοστά του δευτερολέπτου λανθάνοντος χρόνου.
Ταχύτητα κύλισης
Η επόμενη δοκιμή είναι μια παραδοσιακή δοκιμή "ταχύτητας" ή "εύρος ζώνης", η οποία μετρά πόσο γρήγορα το τερματικό μπορεί να πραγματοποιήσει κύλιση σε μια σελίδα ενώ εμφανίζει μεγάλες ποσότητες κειμένου στην οθόνη. Η μηχανική της δοκιμής ποικίλλει. η αρχική δοκιμή ήταν να δημιουργήσει απλώς την ίδια συμβολοσειρά κειμένου χρησιμοποιώντας την εντολή seq. Άλλες δοκιμές περιλαμβάνουν το τεστ του Thomas E. Dickey (xterm συντήρησης), το οποίο επανειλημμένα . Σε μια άλλη ανασκόπηση της απόδοσης του τερματικού χρησιμοποιεί μια κωδικοποιημένη συμβολοσειρά base32 τυχαίων byte, η οποία εξάγεται στο τερματικό χρησιμοποιώντας cat. Ο Luu θεωρεί ότι ένα τέτοιο τεστ είναι «όσο άχρηστο σημείο αναφοράς μπορεί να φανταστεί κανείς» και προτείνει να χρησιμοποιηθεί η τερματική απόκριση ως κύρια μέτρηση. Ο Dickey αποκαλεί επίσης το τεστ του παραπλανητικό. Ωστόσο, και οι δύο συγγραφείς αναγνωρίζουν ότι το εύρος ζώνης του παραθύρου τερματικού μπορεί να είναι πρόβλημα. Ο Luu ανακάλυψε το Emacs Esell να παγώνει κατά την εμφάνιση μεγάλων αρχείων και ο Dickey βελτιστοποίησε το τερματικό για να απαλλαγεί από την οπτική νωθρότητα του xtrerm. Επομένως, υπάρχει ακόμα κάποια αξία σε αυτή τη δοκιμή, αλλά επειδή η διαδικασία απόδοσης είναι πολύ διαφορετική από τερματικό σε τερματικό, μπορεί επίσης να χρησιμοποιηθεί ως εξάρτημα δοκιμής για τη δοκιμή άλλων παραμέτρων.
Εδώ βλέπουμε το rxvt και το st να τραβάει μπροστά από τον ανταγωνισμό, ακολουθούμενο από το πολύ νεότερο Alacritty, το οποίο έχει σχεδιαστεί με έμφαση στην απόδοση. Ακολουθούν τα Xfce (οικογένεια VTE) και Konsole, τα οποία είναι σχεδόν διπλάσια. Το τελευταίο είναι το xterm, το οποίο είναι πέντε φορές πιο αργό από το rxvt. Κατά τη διάρκεια της δοκιμής, το xterm κυματίστηκε επίσης πολύ, καθιστώντας δύσκολο να φανεί το κείμενο με επιτυχία, ακόμη και αν ήταν η ίδια γραμμή. Η Konsole ήταν γρήγορη, αλλά μερικές φορές ήταν δύσκολη: η οθόνη πάγωνε από καιρό σε καιρό, εμφανίζοντας μερικό κείμενο ή δεν εμφανιζόταν καθόλου. Άλλα τερματικά εμφανίζουν ευκρινώς τις συμβολοσειρές, συμπεριλαμβανομένων των st, Alacritty και rxvt.
Ο Dickey εξηγεί ότι οι διαφορές απόδοσης οφείλονται στον σχεδιασμό των buffers κύλισης σε διαφορετικά τερματικά. Συγκεκριμένα, κατηγορεί το rxvt και άλλα τερματικά ότι «δεν τηρούν τους γενικούς κανόνες»:
«Σε αντίθεση με το xterm, το rxvt δεν προσπάθησε να εμφανίσει όλες τις ενημερώσεις. Αν μείνει πίσω, θα αρνηθεί κάποιες ενημερώσεις για να καλύψει τη διαφορά. Αυτό είχε μεγαλύτερη επίδραση στη φαινομενική ταχύτητα κύλισης παρά στην οργάνωση της εσωτερικής μνήμης. Ένα μειονέκτημα ήταν ότι το κινούμενο σχέδιο ASCII ήταν κάπως ανακριβές."
Για να διορθωθεί αυτή η αντιληπτή xterm νωθρότητα, ο Dickey προτείνει τη χρήση του πόρου , επιτρέποντας στο xterm να απορρίψει ορισμένες ενημερώσεις οθόνης για να συμβαδίσει με τη ροή. Οι δοκιμές μου επιβεβαιώνουν ότι το fastScroll βελτιώνει την απόδοση και φέρνει το xterm στο ίδιο επίπεδο με το rxvt. Αυτό είναι, ωστόσο, ένα μάλλον τραχύ δεκανίκι, όπως εξηγεί ο ίδιος ο Dickey: "μερικές φορές το xterm - όπως το konsole - φαίνεται να σταματά καθώς περιμένει για ένα νέο σύνολο ενημερώσεων οθόνης μετά την αφαίρεση ορισμένων". Σε αυτό το πνεύμα, φαίνεται ότι άλλα τερματικά έχουν βρει τον καλύτερο συμβιβασμό μεταξύ της ταχύτητας και της ακεραιότητας της οθόνης.
Κατανάλωση πόρων
Ανεξάρτητα από το αν είναι λογικό να θεωρούμε την ταχύτητα κύλισης ως μέτρηση απόδοσης, αυτή η δοκιμή μας επιτρέπει να προσομοιώσουμε το φορτίο στα τερματικά, το οποίο με τη σειρά του μας επιτρέπει να μετράμε άλλες παραμέτρους, όπως τη χρήση μνήμης ή δίσκου. Οι μετρήσεις ελήφθησαν εκτελώντας την καθορισμένη δοκιμή επόμενα κάτω από την παρακολούθηση διαδικασίας Python. Συνέλεξε δεδομένα μετρητών για ru_maxrss, ποσό ru_oublock и ru_inblock και ένα απλό χρονόμετρο.
Σε αυτή τη δοκιμή, το ST καταλαμβάνει την πρώτη θέση με τη χαμηλότερη μέση κατανάλωση μνήμης των 8 MB, κάτι που δεν προκαλεί έκπληξη δεδομένου ότι η κύρια ιδέα του σχεδιασμού είναι η απλότητα. Τα mlterm, xterm και rxvt καταναλώνουν λίγο περισσότερο - περίπου 12 MB. Ένα άλλο αξιοσημείωτο αποτέλεσμα είναι το Alacritty, το οποίο απαιτεί 30 MB για να τρέξει. Στη συνέχεια, υπάρχουν τερματικά της οικογένειας VTE με αριθμούς από 40 έως 60 MB, που είναι αρκετά. Αυτή η κατανάλωση μπορεί να εξηγηθεί από το γεγονός ότι αυτά τα τερματικά χρησιμοποιούν βιβλιοθήκες υψηλότερου επιπέδου, για παράδειγμα, GTK. Η Konsole έρχεται στην τελευταία θέση με 65MB κατανάλωσης μνήμης κατά τη διάρκεια των δοκιμών, αν και αυτό μπορεί να δικαιολογηθεί από την πολύ μεγάλη γκάμα δυνατοτήτων της.
Σε σύγκριση με προηγούμενα αποτελέσματα που λήφθηκαν πριν από δέκα χρόνια, όλα τα προγράμματα άρχισαν να καταναλώνουν αισθητά περισσότερη μνήμη. Το Xterm απαιτούσε 4 MB, αλλά τώρα απαιτεί 15 MB μόλις κατά την εκκίνηση. Υπάρχει παρόμοια αύξηση στην κατανάλωση για το rxvt, το οποίο απαιτεί πλέον 16 MB από το κουτί. Το Xfce Terminal καταλαμβάνει 34 MB, το οποίο είναι τρεις φορές μεγαλύτερο από πριν, αλλά το τερματικό GNOME απαιτεί μόνο 20 MB. Φυσικά, όλες οι προηγούμενες δοκιμές πραγματοποιήθηκαν σε αρχιτεκτονική 32-bit. Στο LCA 2012 Rusty Russell , ότι υπάρχουν πολλοί πιο λεπτοί λόγοι που θα μπορούσαν να εξηγήσουν την αύξηση της κατανάλωσης μνήμης. Τούτου λεχθέντος, τώρα ζούμε σε μια εποχή που έχουμε gigabytes μνήμης, οπότε με κάποιο τρόπο θα τα καταφέρουμε.
Ωστόσο, δεν μπορώ παρά να αισθάνομαι ότι η διάθεση περισσότερης μνήμης σε κάτι τόσο θεμελιώδες όπως το τερματικό είναι σπατάλη πόρων. Αυτά τα προγράμματα θα πρέπει να είναι τα μικρότερα από τα μικρότερα, θα πρέπει να μπορούν να εκτελούνται σε οποιοδήποτε «κουτί», ακόμα και σε κουτί παπουτσιών, αν φτάσουμε ποτέ στο σημείο όπου πρέπει να εξοπλιστούν με συστήματα Linux (και ξέρετε ότι θα είναι έτσι ) . Αλλά με αυτούς τους αριθμούς, η χρήση της μνήμης θα αποτελέσει πρόβλημα στο μέλλον σε οποιοδήποτε περιβάλλον που διαθέτει πολλαπλά τερματικά εκτός από μερικά από τα ελαφρύτερα και πιο περιορισμένες σε δυνατότητες. Για να αντισταθμιστεί αυτό, τα GNOME Terminal, Konsole, urxvt, Terminator και Xfce Terminal έχουν μια λειτουργία Daemon που σας επιτρέπει να ελέγχετε πολλαπλά τερματικά μέσω μιας διαδικασίας, περιορίζοντας την κατανάλωση μνήμης τους.
Κατά τη διάρκεια των δοκιμών μου, κατέληξα σε ένα άλλο απροσδόκητο αποτέλεσμα σχετικά με την ανάγνωση-εγγραφή δίσκου: περίμενα να μην δω απολύτως τίποτα εδώ, αλλά αποδείχθηκε ότι ορισμένα τερματικά γράφουν τα πιο ογκώδη δεδομένα στο δίσκο. Έτσι, η βιβλιοθήκη VTE διατηρεί στην πραγματικότητα ένα buffer κύλισης στο δίσκο (αυτή η δυνατότητα , και αυτό εξακολουθεί να συμβαίνει). Αλλά σε αντίθεση με παλαιότερες υλοποιήσεις, τώρα τουλάχιστον αυτά τα δεδομένα είναι κρυπτογραφημένα χρησιμοποιώντας AES256 GCM (). Αλλά τίθεται ένα εύλογο ερώτημα: τι είναι τόσο ιδιαίτερο για τη βιβλιοθήκη VTE που απαιτεί μια τόσο μη τυποποιημένη προσέγγιση στην υλοποίηση...
Συμπέρασμα
Στο πρώτο μέρος του άρθρου, διαπιστώσαμε ότι τα τερματικά που βασίζονται σε VTE έχουν ένα καλό σύνολο χαρακτηριστικών, αλλά τώρα βλέπουμε ότι αυτό συνοδεύεται από κάποιο κόστος απόδοσης. Τώρα η μνήμη δεν είναι πρόβλημα επειδή όλα τα τερματικά VTE μπορούν να ελεγχθούν μέσω μιας διαδικασίας Daemon, η οποία περιορίζει την όρεξή τους. Ωστόσο, παλαιότερα συστήματα που έχουν φυσικούς περιορισμούς στην ποσότητα της μνήμης RAM και των buffer του πυρήνα μπορεί να χρειάζονται ακόμα προηγούμενες εκδόσεις τερματικών, καθώς καταναλώνουν σημαντικά λιγότερους πόρους. Αν και τα τερματικά VTE απέδωσαν καλά σε δοκιμές διεκπεραίωσης (κύλιση), η καθυστέρηση εμφάνισης τους είναι πάνω από το όριο που έχει οριστεί στον Οδηγό χρήσης του GNOME. Οι προγραμματιστές VTE θα πρέπει πιθανώς να το λάβουν υπόψη. Αν λάβουμε υπόψη ότι ακόμη και για αρχάριους χρήστες Linux η συνάντηση με ένα τερματικό είναι αναπόφευκτη, μπορούν να το κάνουν πιο φιλικό προς τον χρήστη. Για τους έμπειρους geeks, η εναλλαγή από το προεπιλεγμένο τερματικό μπορεί να σημαίνει ακόμη και λιγότερη καταπόνηση των ματιών και τη δυνατότητα αποφυγής μελλοντικών τραυματισμών και ασθενειών που σχετίζονται με την εργασία λόγω μακρών συνεδριών εργασίας. Δυστυχώς, μόνο το παλιό xterm και mlterm μας φέρνουν στο μαγικό όριο ping των 10 χιλιοστών του δευτερολέπτου, το οποίο είναι απαράδεκτο για πολλούς.
Οι μετρήσεις συγκριτικής αξιολόγησης έδειξαν επίσης ότι λόγω της ανάπτυξης γραφικών περιβαλλόντων Linux, οι προγραμματιστές έπρεπε να κάνουν μια σειρά από συμβιβασμούς. Ορισμένοι χρήστες μπορεί να θέλουν να κοιτάξουν τους κανονικούς διαχειριστές παραθύρων καθώς παρέχουν σημαντική μείωση του ping. Δυστυχώς, δεν ήταν δυνατό να μετρηθεί η καθυστέρηση για το Wayland: το πρόγραμμα Typometer που χρησιμοποίησα δημιουργήθηκε για αυτό που η Wayland έχει σχεδιαστεί για να αποτρέπει: την κατασκοπεία άλλων παραθύρων. Ελπίζω ότι το Wayland compositing έχει καλύτερη απόδοση από το X.org και ελπίζω επίσης ότι στο μέλλον κάποιος θα βρει έναν τρόπο να μετρήσει την καθυστέρηση σε αυτό το περιβάλλον.
Πηγή: www.habr.com