Đôi lời từ văn phòng dịch thuật của chúng tôi: thông thường mọi người đều cố gắng dịch các tài liệu và ấn phẩm mới nhất, và chúng tôi cũng không ngoại lệ. Nhưng thiết bị đầu cuối không phải là thứ được cập nhật mỗi tuần một lần. Vì vậy, chúng tôi đã dịch cho bạn một bài viết của Antoine Beaupré, xuất bản vào mùa xuân năm 2018: mặc dù đã có “tuổi đời” đáng kể theo tiêu chuẩn hiện đại, nhưng theo quan điểm của chúng tôi, tài liệu này vẫn không hề mất đi tính liên quan của nó. Ngoài ra, ban đầu đây là một chuỗi gồm hai bài viết, nhưng chúng tôi quyết định kết hợp chúng thành một bài lớn.
Thiết bị đầu cuối có một vị trí đặc biệt trong lịch sử máy tính, nhưng trong những thập kỷ gần đây, chúng buộc phải tồn tại bên cạnh dòng lệnh khi giao diện đồ họa trở nên phổ biến. thay thế của riêng họ , đến lượt nó, là một sửa đổi của hệ thống dựa trên thẻ đục lỗ và công tắc bật tắt. Các bản phân phối hiện đại đi kèm với nhiều trình mô phỏng thiết bị đầu cuối với đủ hình dạng và màu sắc. Và trong khi nhiều người hài lòng với thiết bị đầu cuối tiêu chuẩn do môi trường làm việc của họ cung cấp, một số lại tự hào sử dụng phần mềm hết sức kỳ lạ để chạy trình soạn thảo văn bản hoặc shell yêu thích của họ. Tuy nhiên, như chúng ta sẽ thấy trong bài viết này, không phải tất cả các thiết bị đầu cuối đều được tạo theo cùng một hình ảnh: chúng khác nhau rất nhiều về chức năng, kích thước và hiệu suất.
Một số thiết bị đầu cuối có những lỗ hổng bảo mật đáng ngạc nhiên, ngoài ra hầu hết đều có một bộ chức năng hoàn toàn khác, từ hỗ trợ giao diện theo thẻ cho đến tập lệnh. Mặc dù chúng tôi , bài viết này là bản cập nhật của tài liệu trước đó sẽ giúp người đọc xác định nên sử dụng thiết bị đầu cuối nào trong năm 2018. Nửa đầu bài viết so sánh tính năng, nửa sau đánh giá hiệu năng.
Đây là các thiết bị đầu cuối tôi đã xem xét:
Đây có thể không phải là phiên bản mới nhất, vì tại thời điểm viết bài, tôi bị giới hạn ở các bản dựng ổn định mà tôi có thể triển khai trên Debian 9 hoặc Fedora 27. Ngoại lệ duy nhất là Alacritty. Nó là hậu duệ của các thiết bị đầu cuối được tăng tốc GPU và được viết bằng một ngôn ngữ mới và khác thường cho tác vụ này - Rust. Tôi đã loại trừ các thiết bị đầu cuối web khỏi đánh giá của mình (bao gồm cả những thiết bị trên ), bởi vì các thử nghiệm sơ bộ cho thấy hiệu suất cực kỳ kém của chúng.
Hỗ trợ Unicode
Tôi bắt đầu thử nghiệm với sự hỗ trợ Unicode. Thử nghiệm đầu tiên của thiết bị đầu cuối là hiển thị chuỗi Unicode từ : “é, Δ, И, ק, م, ๗, あ, 叶, 葉 và 말.” Thử nghiệm đơn giản này cho thấy liệu thiết bị đầu cuối có thể hoạt động chính xác trên toàn thế giới hay không. thiết bị đầu cuối xterm không hiển thị ký tự tiếng Ả Rập trong cấu hình mặc định:
Theo mặc định, xterm sử dụng phông chữ "cố định" cổ điển, theo , có "phạm vi phủ sóng Unicode đáng kể kể từ năm 1997". Có điều gì đó đang xảy ra với phông chữ này khiến ký tự xuất hiện dưới dạng khung trống và chỉ khi phông chữ văn bản được tăng lên hơn 20 điểm thì ký tự cuối cùng mới bắt đầu hiển thị chính xác. Tuy nhiên, cách “sửa lỗi” này làm hỏng việc hiển thị các ký tự Unicode khác:
Những ảnh chụp màn hình này được chụp trong Fedora 27, vì nó cho kết quả tốt hơn Debian 9, trong đó một số phiên bản thiết bị đầu cuối cũ hơn (cụ thể là mlterm) không thể xử lý phông chữ đúng cách. May mắn thay điều này đã được sửa trong các phiên bản sau.
Bây giờ hãy chú ý cách dòng này được hiển thị trong xterm. Hóa ra ký hiệu Mem và tiếng Semitic sau đây tham khảo các tập lệnh kiểu RTL (), vì vậy về mặt kỹ thuật chúng phải được hiển thị từ phải sang trái. Các trình duyệt web như Firefox 57 xử lý dòng trên một cách chính xác. Một phiên bản đơn giản hơn của văn bản RTL là từ "" bằng tiếng Do Thái (). nói như sau:
“Nhiều chương trình máy tính không thể hiển thị chính xác văn bản hai chiều. Ví dụ: tên tiếng Do Thái "Sarah" bao gồm các ký tự sin (ש) (xuất hiện ở bên phải), sau đó là resh (ר) và cuối cùng là he (ה) (xuất hiện ở bên trái)."
Nhiều thiết bị đầu cuối không đạt được bài kiểm tra này: các thiết bị đầu cuối Alacritty, Gnome và XFCE có nguồn gốc từ VTE, urxvt, st và xterm hiển thị "Sara" theo thứ tự ngược lại, như thể chúng tôi đã viết tên là "Aras".
Một vấn đề khác với văn bản hai chiều là chúng cần được căn chỉnh bằng cách nào đó, đặc biệt là khi trộn văn bản RTL và LTR. Các tập lệnh RTL sẽ chạy từ phía bên phải của cửa sổ terminal, nhưng điều gì sẽ xảy ra với các terminal mặc định sử dụng LTR English? Hầu hết chúng không có bất kỳ cơ chế đặc biệt nào và căn chỉnh tất cả văn bản sang trái (kể cả trong Konsole). Các trường hợp ngoại lệ là pterm và mlterm, tuân thủ các tiêu chuẩn và căn chỉnh các dòng đó.
Bảo vệ chèn
Tính năng quan trọng tiếp theo mà tôi đã xác định là bảo vệ chống chèn. Mặc dù người ta biết rộng rãi rằng những câu thần chú như:
$ curl http://example.com/ | shLà các lệnh đẩy thực thi mã, ít người biết rằng các lệnh ẩn có thể lẻn vào bảng điều khiển khi sao chép và dán từ trình duyệt web, ngay cả sau khi kiểm tra cẩn thận. cho thấy một cách xuất sắc lệnh này trông có vẻ vô hại như thế nào:
git clone git: //git.kernel.org/pub/scm/utils/kup/kup.gittrở nên phiền toái khi dán từ trang web của Horn vào thiết bị đầu cuối:
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.gitLàm thế nào nó hoạt động? Mã độc hại được bao gồm trong khối , được chuyển ra khỏi chế độ xem của người dùng bằng CSS.
được thiết kế rõ ràng để vô hiệu hóa các cuộc tấn công như vậy. Trong chế độ này, các thiết bị đầu cuối bao bọc văn bản được dán trong một cặp chuỗi thoát đặc biệt để báo cho shell về nguồn gốc của văn bản. Điều này cho shell biết rằng nó có thể bỏ qua các ký tự đặc biệt mà văn bản được dán có thể chứa. Tất cả các thiết bị đầu cuối trở lại xterm đáng kính đều hỗ trợ tính năng này, nhưng việc dán ở chế độ Bracketed yêu cầu hỗ trợ từ shell hoặc ứng dụng chạy trên thiết bị đầu cuối. Ví dụ như phần mềm sử dụng (cùng Bash), cần một tập tin ~/.inputrc:
set enable-bracketed-paste onThật không may, trang web thử nghiệm của Horn cũng chỉ ra cách vượt qua sự bảo vệ này thông qua chính định dạng văn bản và sớm áp dụng chế độ Bracketed cho nó. Điều này hoạt động vì một số thiết bị đầu cuối không lọc chính xác các chuỗi thoát trước khi thêm chuỗi thoát của chúng. Ví dụ: với tôi, tôi chưa bao giờ có thể hoàn thành thành công các bài kiểm tra Konsole ngay cả với cấu hình chính xác .inputrc tài liệu. Điều này có nghĩa là bạn có thể dễ dàng làm hỏng cấu hình hệ thống của mình do ứng dụng không được hỗ trợ hoặc do shell được cấu hình không chính xác. Điều này đặc biệt nguy hiểm khi đăng nhập vào các máy chủ từ xa, nơi mà công việc cấu hình cẩn thận ít phổ biến hơn, đặc biệt nếu bạn có nhiều máy từ xa như vậy.
Một giải pháp tốt cho vấn đề này là plugin xác nhận dán cho terminal urxvt, chỉ cần yêu cầu quyền chèn bất kỳ văn bản nào có chứa dòng mới. Tôi chưa tìm thấy tùy chọn nào an toàn hơn cho cuộc tấn công bằng văn bản được Horn mô tả.
Tab và hồ sơ
Một tính năng phổ biến hiện nay là hỗ trợ giao diện theo thẻ, mà chúng tôi sẽ định nghĩa là một cửa sổ đầu cuối chứa một số thiết bị đầu cuối khác. Chức năng này khác nhau đối với các thiết bị đầu cuối khác nhau và mặc dù các thiết bị đầu cuối xterm truyền thống hoàn toàn không hỗ trợ các tab, các phiên bản thiết bị đầu cuối hiện đại hơn như Xfce Terminal, GNOME Terminal và Konsole vẫn có chức năng này. Urxvt cũng hỗ trợ các tab nhưng chỉ khi bạn sử dụng plugin. Nhưng về mặt hỗ trợ tab, Terminator là người dẫn đầu không thể tranh cãi: nó không chỉ hỗ trợ các tab mà còn có thể sắp xếp các thiết bị đầu cuối theo bất kỳ thứ tự nào (xem hình ảnh bên dưới).
Một tính năng khác của Terminator là khả năng "nhóm" các tab này lại với nhau và gửi cùng một lần nhấn phím đến nhiều thiết bị đầu cuối cùng lúc, cung cấp một công cụ thô sơ để thực hiện đồng thời các thao tác hàng loạt trên nhiều máy chủ. Một tính năng tương tự cũng được triển khai trong Konsole. Để sử dụng tính năng này trong các thiết bị đầu cuối khác, bạn phải sử dụng phần mềm của bên thứ ba như , hoặc .
Các tab hoạt động đặc biệt tốt khi được ghép nối với hồ sơ: ví dụ: bạn có thể có một tab cho email, một tab khác để trò chuyện, v.v. Điều này được hỗ trợ tốt bởi Konsole Terminal và Gnome Terminal. Cả hai đều cho phép mỗi tab tự động khởi chạy hồ sơ riêng của nó. Terminator cũng hỗ trợ cấu hình, nhưng tôi không thể tìm cách tự động khởi chạy một số chương trình nhất định khi bạn mở một tab cụ thể. Các thiết bị đầu cuối khác hoàn toàn không có khái niệm về “hồ sơ”.
Xù lông
Điều cuối cùng tôi sẽ đề cập đến trong phần đầu của bài viết này là sự xuất hiện của các thiết bị đầu cuối. Ví dụ: Gnome, Xfce và urxvt hỗ trợ tính minh bạch, nhưng gần đây đã bỏ hỗ trợ cho hình nền, buộc một số người dùng phải chuyển sang thiết bị đầu cuối . Cá nhân tôi hài lòng với nó và nó đơn giản xresources, đặt tập hợp màu nền cơ bản cho urxvt. Tuy nhiên, chủ đề màu sắc không chuẩn cũng có thể gây ra vấn đề. Ví dụ, với các ứng dụng и , vì họ đã sử dụng màu sắc riêng của mình.
không hỗ trợ màu sắc và những màu mới thường bị giới hạn ở bảng màu 256 màu. Đối với những người dùng nâng cao muốn tạo kiểu cho thiết bị đầu cuối của họ, lời nhắc shell hoặc thanh trạng thái theo những cách phức tạp có thể là một hạn chế khó chịu. theo dõi thiết bị đầu cuối nào có hỗ trợ "True Color". Các thử nghiệm của tôi xác nhận rằng các thiết bị đầu cuối dựa trên st, Alacritty và VTE hỗ trợ True Color một cách hoàn hảo. Các thiết bị đầu cuối khác không hoạt động tốt về mặt này và trên thực tế, thậm chí không hiển thị 256 màu. Dưới đây, bạn có thể thấy sự khác biệt giữa hỗ trợ True Color trong các thiết bị đầu cuối Gnome, st và xterm, thực hiện tốt điều này với bảng màu 256 của chúng và urxvt, không chỉ thất bại trong quá trình kiểm tra mà thậm chí còn hiển thị một số ký tự nhấp nháy thay thế chúng.
Một số thiết bị đầu cuối cũng phân tích văn bản cho các mẫu URL để tạo liên kết có thể nhấp vào được. Điều này áp dụng cho tất cả các thiết bị đầu cuối có nguồn gốc từ VTE, trong khi urxvt yêu cầu một plugin đặc biệt có thể chuyển đổi URL chỉ bằng một cú nhấp chuột hoặc sử dụng phím tắt. Các thiết bị đầu cuối khác Tôi đã thử nghiệm các URL hiển thị theo những cách khác.
Cuối cùng, một xu hướng mới trong thiết bị đầu cuối là tính tùy chọn của bộ đệm cuộn. Ví dụ: st không có bộ đệm cuộn; giả định rằng người dùng sẽ sử dụng bộ ghép kênh đầu cuối như tmux và .
Alacritty cũng thiếu bộ đệm cuộn ngược, nhưng sự hỗ trợ của nó nhờ “phản hồi rộng rãi” về chủ đề này từ người dùng. Ngoài những thiết bị mới nổi này, mọi thiết bị đầu cuối mà tôi đã thử nghiệm đều hỗ trợ cuộn ngược.
Tổng phụ
Trong phần thứ hai của tài liệu (trong bản gốc đây là hai bài viết khác nhau - khoảng. làn đường) chúng tôi sẽ so sánh hiệu suất, mức sử dụng bộ nhớ và độ trễ. Nhưng chúng ta có thể thấy rằng một số thiết bị đầu cuối được đề cập có những thiếu sót nghiêm trọng. Ví dụ: người dùng thường xuyên làm việc với các tập lệnh RTL có thể muốn xem xét mlterm và pterm, vì chúng xử lý các tác vụ tương tự tốt hơn các tác vụ khác. Konsole cũng hoạt động tốt. Người dùng không làm việc với tập lệnh RTL có thể chọn thứ khác.
Về khả năng bảo vệ chống lại việc chèn mã độc, urxvt nổi bật nhờ khả năng bảo vệ đặc biệt chống lại kiểu tấn công này, điều này có vẻ rất thuận tiện đối với tôi. Đối với những người đang tìm kiếm một số tính năng thú vị, Konsole đáng để xem xét. Cuối cùng, điều đáng chú ý là VTE là cơ sở tuyệt vời cho thiết bị đầu cuối, đảm bảo hỗ trợ màu sắc, nhận dạng URL, v.v. Thoạt nhìn, thiết bị đầu cuối mặc định đi kèm với môi trường yêu thích của bạn có thể đáp ứng tất cả các yêu cầu, nhưng hãy để câu hỏi này mở cho đến khi chúng tôi hiểu được hiệu suất.
Chúng tôi tiếp tục cuộc trò chuyện
Nhìn chung, bản thân hiệu suất của các thiết bị đầu cuối có vẻ như là một vấn đề xa vời, nhưng hóa ra, một số trong số chúng có độ trễ cao đáng ngạc nhiên đối với phần mềm thuộc loại cơ bản như vậy. Ngoài ra, tiếp theo, chúng ta sẽ xem xét cái được gọi theo truyền thống là “tốc độ” (trên thực tế, đây là tốc độ cuộn) và mức tiêu thụ bộ nhớ của thiết bị đầu cuối (với lời cảnh báo rằng ngày nay điều này không còn quan trọng như nhiều thập kỷ trước).
Trì hoãn
Sau khi nghiên cứu kỹ lưỡng về hiệu suất của thiết bị đầu cuối, tôi đi đến kết luận rằng thông số quan trọng nhất trong vấn đề này là độ trễ (ping). Trong bài viết của anh ấy Pavel Fatin đã xem xét độ trễ của nhiều trình soạn thảo văn bản khác nhau và gợi ý rằng các thiết bị đầu cuối về mặt này có thể chậm hơn các trình soạn thảo văn bản nhanh nhất. Chính gợi ý này cuối cùng đã dẫn tôi đến việc chạy thử nghiệm của riêng mình và viết bài viết này.
Nhưng độ trễ là gì và tại sao nó lại quan trọng đến vậy? Trong bài viết của mình, Fatin định nghĩa nó là “độ trễ giữa việc nhấn phím và cập nhật màn hình tương ứng” và trích dẫn , trong đó nêu rõ: “Sự chậm trễ trong phản hồi hình ảnh trên màn hình máy tính có tác động quan trọng đến hành vi và sự hài lòng của người đánh máy.”
Fatin giải thích rằng tiếng ping này có những hậu quả sâu sắc hơn là chỉ mang lại sự hài lòng: “việc gõ phím trở nên chậm hơn, xảy ra nhiều lỗi hơn và độ căng của mắt và cơ tăng lên”. Nói cách khác, độ trễ lớn có thể dẫn đến lỗi chính tả và chất lượng mã thấp hơn, vì nó dẫn đến tải nhận thức bổ sung lên não. Nhưng điều tệ hơn là ping "làm tăng căng thẳng cho mắt và cơ", điều này dường như ám chỉ trong tương lai (Rõ ràng, tác giả muốn nói đến các vấn đề với cơ mắt, lưng, cánh tay và tất nhiên là cả thị lực - khoảng. làn đường) do căng thẳng lặp đi lặp lại.
Một số tác dụng này đã được biết đến từ lâu và kết quả , được xuất bản vào năm 1976 trên tạp chí Ergonomics, cho biết độ trễ 100 mili giây "làm giảm đáng kể tốc độ gõ". Gần đây hơn, Hướng dẫn sử dụng Gnome đã giới thiệu trong 10 mili giây và nếu bạn đi xa hơn thì cho thấy 1 mili giây là lý tưởng.
Fatin đã tiến hành thử nghiệm của mình trên các trình soạn thảo văn bản; ông đã tạo ra một nhạc cụ cầm tay có tên là , mà tôi đã sử dụng để kiểm tra ping trong trình mô phỏng thiết bị đầu cuối. Hãy nhớ rằng thử nghiệm được tiến hành ở chế độ mô phỏng: trên thực tế, chúng ta cần tính đến độ trễ của cả đầu vào (bàn phím, bộ điều khiển USB, v.v.) và đầu ra (bộ đệm card màn hình, màn hình). Theo Fatin, trong cấu hình thông thường, tốc độ này là khoảng 20 mili giây. Nếu bạn có thiết bị chơi game, bạn có thể đạt được con số này chỉ trong 3 mili giây. Vì chúng ta đã có phần cứng nhanh như vậy nên ứng dụng không cần phải thêm độ trễ của riêng nó. Mục tiêu của Fatin là đưa độ trễ của ứng dụng lên 1 mili giây hoặc thậm chí đạt được khả năng quay số mà không cần , Làm thế nào .
Dưới đây là kết quả đo lường của tôi, cũng như một số kết quả của Fatin, để cho thấy rằng thí nghiệm của tôi phù hợp với các thử nghiệm của anh ấy:
Điều đầu tiên khiến tôi ấn tượng là thời gian phản hồi tốt hơn của các chương trình cũ như xterm và mlterm. Với độ trễ đăng ký tệ nhất (2,4 ms), chúng hoạt động tốt hơn thiết bị đầu cuối hiện đại nhanh nhất (10,6 ms cho st). Không có thiết bị đầu cuối hiện đại nào giảm xuống dưới ngưỡng 10 mili giây. Đặc biệt, Alacritty không đáp ứng được yêu cầu "trình mô phỏng thiết bị đầu cuối nhanh nhất hiện có", mặc dù điểm số của nó đã được cải thiện kể từ lần đánh giá đầu tiên vào năm 2017. Thực tế, các tác giả của dự án và đang làm việc để cải thiện màn hình. Cũng cần lưu ý rằng Vim sử dụng GTK3 chậm hơn rất nhiều so với phiên bản GTK2 của nó. Từ đó, chúng tôi có thể kết luận rằng GTK3 tạo ra độ trễ bổ sung và điều này được phản ánh trong tất cả các thiết bị đầu cuối khác sử dụng nó (Terminator, Xfce4 Terminal và GNOME Terminal).
Tuy nhiên, sự khác biệt có thể không được nhận thấy bằng mắt. Như Fatin giải thích, “bạn không cần phải nhận thức được sự chậm trễ thì nó mới ảnh hưởng đến bạn”. Fatin cũng cảnh báo về độ lệch chuẩn: “bất kỳ sự xáo trộn nào về độ trễ (jitter) đều tạo thêm căng thẳng do tính không thể đoán trước của chúng”.
Biểu đồ trên được lấy trên Debian 9 thuần túy (kéo dài) với . Môi trường này tạo ra kết quả tốt nhất trong các bài kiểm tra độ trễ. Hóa ra, Gnome tạo thêm ping 20 ms cho tất cả các phép đo. Một lời giải thích khả dĩ cho điều này là sự hiện diện của các chương trình xử lý đồng bộ các sự kiện đầu vào. Fatin đưa ra một ví dụ cho trường hợp này , điều này thêm độ trễ bằng cách xử lý đồng bộ tất cả các sự kiện đầu vào. Theo mặc định, Gnome cũng đi kèm với trình quản lý cửa sổ , tạo ra một lớp đệm bổ sung, ảnh hưởng đến ping và tăng thêm độ trễ ít nhất 8 mili giây.
Tốc độ cuộn
Thử nghiệm tiếp theo là thử nghiệm "tốc độ" hoặc "băng thông" truyền thống, đo lường tốc độ thiết bị đầu cuối có thể cuộn một trang trong khi hiển thị lượng lớn văn bản trên màn hình. Cơ chế của bài kiểm tra khác nhau; thử nghiệm ban đầu chỉ đơn giản là tạo ra cùng một chuỗi văn bản bằng lệnh seq. Các thử nghiệm khác bao gồm thử nghiệm (người duy trì xterm) của Thomas E. Dickey, thử nghiệm này lặp đi lặp lại . Trong một đánh giá khác về hiệu suất thiết bị đầu cuối sử dụng chuỗi byte ngẫu nhiên được mã hóa base32, được xuất ra thiết bị đầu cuối bằng cách sử dụng cat. Lưu coi bài kiểm tra như vậy là "một điểm chuẩn vô dụng như người ta có thể tưởng tượng" và thay vào đó đề xuất sử dụng phản hồi của thiết bị đầu cuối làm thước đo chính. Dickey cũng cho rằng bài kiểm tra của mình là sai lệch. Tuy nhiên, cả hai tác giả đều thừa nhận rằng băng thông cửa sổ đầu cuối có thể là một vấn đề. Lưu phát hiện ra Emacs Eshell bị treo khi hiển thị các tệp lớn và Dickey đã tối ưu hóa thiết bị đầu cuối để loại bỏ tình trạng chậm chạp về mặt hình ảnh của xtrerm. Vì vậy, thử nghiệm này vẫn có một số giá trị, nhưng vì quá trình kết xuất rất khác nhau giữa các thiết bị đầu cuối nên nó cũng có thể được sử dụng làm thành phần thử nghiệm để kiểm tra các tham số khác.
Ở đây, chúng ta thấy rxvt và st vượt lên dẫn trước đối thủ, tiếp theo là Alacritty mới hơn nhiều, được thiết kế tập trung vào hiệu suất. Tiếp theo là Xfce (họ VTE) và Konsole, nhanh gần gấp đôi. Cuối cùng là xterm, chậm hơn năm lần so với rxvt. Trong quá trình thử nghiệm, xterm cũng bị gợn sóng rất nhiều, khiến văn bản truyền qua khó nhìn thấy ngay cả khi cùng một dòng. Konsole rất nhanh nhưng đôi khi cũng gặp khó khăn: màn hình thỉnh thoảng bị treo, hiển thị một phần văn bản hoặc hoàn toàn không hiển thị. Các thiết bị đầu cuối khác hiển thị các chuỗi rõ ràng, bao gồm st, Alacritty và rxvt.
Dickey giải thích rằng sự khác biệt về hiệu suất là do thiết kế bộ đệm cuộn ở các thiết bị đầu cuối khác nhau. Đặc biệt, anh ta cáo buộc rxvt và các thiết bị đầu cuối khác “không tuân theo các quy tắc chung”:
“Không giống như xterm, rxvt không cố gắng hiển thị tất cả các bản cập nhật. Nếu tụt lại phía sau, nó sẽ từ chối một số cập nhật để bắt kịp. Điều này có tác động lớn hơn đến tốc độ cuộn rõ ràng hơn là tổ chức bộ nhớ trong. Một nhược điểm là hoạt ảnh ASCII có phần không chính xác."
Để khắc phục tình trạng chậm chạp được nhận thấy trong xterm này, Dickey đề xuất sử dụng tài nguyên , cho phép xterm loại bỏ một số cập nhật màn hình để theo kịp tiến trình. Các thử nghiệm của tôi xác nhận rằng fastScroll cải thiện hiệu suất và mang xterm ngang bằng với rxvt. Tuy nhiên, đây là một chiếc nạng khá khó khăn, như chính Dickey giải thích: "đôi khi xterm - giống như konsole - dường như bị đình trệ khi nó chờ một bộ cập nhật màn hình mới sau khi một số đã bị xóa." Theo hướng này, có vẻ như các thiết bị đầu cuối khác đã tìm ra sự thỏa hiệp tốt nhất giữa tốc độ và tính toàn vẹn của màn hình.
Tiêu thụ tài nguyên
Bất kể việc coi tốc độ cuộn là thước đo hiệu suất có hợp lý hay không, thử nghiệm này cho phép chúng tôi mô phỏng tải trên thiết bị đầu cuối, từ đó cho phép chúng tôi đo các thông số khác như mức sử dụng bộ nhớ hoặc ổ đĩa. Các số liệu thu được bằng cách chạy thử nghiệm được chỉ định seq dưới sự giám sát quá trình Python. Anh ấy đã thu thập dữ liệu đồng hồ cho ru_maxrss, số lượng ru_oublock и ru_inblock và một bộ đếm thời gian đơn giản.
Trong thử nghiệm này, ST chiếm vị trí đầu tiên với mức tiêu thụ bộ nhớ trung bình thấp nhất là 8 MB, điều này không có gì đáng ngạc nhiên khi ý tưởng chính của thiết kế là sự đơn giản. mlterm, xterm và rxvt tiêu thụ nhiều hơn một chút - khoảng 12 MB. Một kết quả đáng chú ý khác là Alacritty, yêu cầu 30 MB để chạy. Sau đó là các thiết bị đầu cuối thuộc họ VTE với dung lượng từ 40 đến 60 MB, khá nhiều. Mức tiêu thụ này có thể được giải thích là do các thiết bị đầu cuối này sử dụng các thư viện cấp cao hơn, chẳng hạn như GTK. Konsole đứng cuối cùng với mức tiêu thụ bộ nhớ khổng lồ 65 MB trong các thử nghiệm, mặc dù điều này có thể được chứng minh bằng rất nhiều tính năng của nó.
So với kết quả trước đó thu được cách đây 4 năm, tất cả các chương trình bắt đầu tiêu tốn nhiều bộ nhớ hơn đáng kể. Xterm trước đây yêu cầu 15 MB, nhưng bây giờ nó chỉ cần 16 MB khi khởi động. Mức tiêu thụ dành cho rxvt cũng tăng tương tự, hiện yêu cầu 34 MB khi sử dụng ngay. Thiết bị đầu cuối Xfce chiếm 20 MB, lớn hơn gấp ba lần so với trước đây, nhưng Thiết bị đầu cuối Gnome chỉ yêu cầu 32 MB. Tất nhiên, tất cả các thử nghiệm trước đó đều được thực hiện trên kiến trúc 2012 bit. Tại LCA XNUMX Rusty Russell , rằng có nhiều lý do tinh vi hơn có thể giải thích cho việc tăng mức tiêu thụ bộ nhớ. Phải nói rằng, hiện nay chúng ta đang sống trong thời đại mà chúng ta có hàng gigabyte bộ nhớ, vì vậy chúng ta sẽ quản lý bằng cách nào đó.
Tuy nhiên, tôi không thể không cảm thấy rằng việc phân bổ nhiều bộ nhớ hơn cho những thứ cơ bản như thiết bị đầu cuối là một sự lãng phí tài nguyên. Các chương trình này phải là chương trình nhỏ nhất trong số nhỏ nhất, có thể chạy trên bất kỳ “hộp” nào, thậm chí là hộp đựng giày, nếu chúng ta đến lúc chúng cần được trang bị hệ thống Linux (và bạn biết rằng nó sẽ như vậy). ) . Nhưng với những con số này, việc sử dụng bộ nhớ sẽ trở thành một vấn đề trong tương lai trong bất kỳ môi trường nào chạy nhiều thiết bị đầu cuối ngoại trừ một số thiết bị nhẹ nhất và hạn chế nhất về khả năng. Để bù đắp cho điều này, GNOME Terminal, Konsole, urxvt, Terminator và Xfce Terminal có chế độ Daemon cho phép bạn điều khiển nhiều thiết bị đầu cuối thông qua một quy trình duy nhất, hạn chế mức tiêu thụ bộ nhớ của chúng.
Trong các thử nghiệm của mình, tôi đã nhận được một kết quả không mong muốn khác liên quan đến việc đọc-ghi đĩa: Tôi đã mong đợi không thấy gì ở đây, nhưng hóa ra một số thiết bị đầu cuối ghi dữ liệu lớn nhất vào đĩa. Vì vậy, thư viện VTE thực sự giữ một bộ đệm cuộn trên đĩa (tính năng này , và điều này vẫn đang xảy ra). Nhưng không giống như các triển khai cũ hơn, giờ đây ít nhất dữ liệu này được mã hóa bằng AES256 GCM (). Nhưng một câu hỏi hợp lý được đặt ra: thư viện VTE có gì đặc biệt đến mức nó đòi hỏi một cách tiếp cận không chuẩn như vậy để triển khai...
Kết luận
Trong phần đầu của bài viết, chúng tôi nhận thấy rằng các thiết bị đầu cuối dựa trên VTE có một bộ tính năng tốt, nhưng bây giờ chúng tôi thấy rằng điều này đi kèm với một số chi phí về hiệu suất. Bây giờ bộ nhớ không phải là vấn đề vì tất cả các thiết bị đầu cuối VTE có thể được kiểm soát thông qua quy trình Daemon, điều này hạn chế sự thèm ăn của chúng. Tuy nhiên, các hệ thống cũ có giới hạn vật lý về dung lượng RAM và bộ đệm nhân vẫn có thể cần các phiên bản thiết bị đầu cuối cũ hơn vì chúng tiêu thụ ít tài nguyên hơn đáng kể. Mặc dù các thiết bị đầu cuối VTE hoạt động tốt trong các thử nghiệm thông lượng (cuộn), độ trễ hiển thị của chúng vẫn cao hơn ngưỡng được đặt trong Hướng dẫn sử dụng Gnome. Các nhà phát triển VTE có lẽ nên tính đến điều này. Nếu chúng tôi tính đến việc ngay cả đối với những người mới sử dụng Linux, việc gặp phải thiết bị đầu cuối là điều không thể tránh khỏi, thì họ có thể làm cho nó thân thiện hơn với người dùng. Đối với những người đam mê công nghệ có kinh nghiệm, việc chuyển từ thiết bị đầu cuối mặc định thậm chí có thể giúp giảm mỏi mắt hơn và có khả năng tránh được các chấn thương và bệnh tật liên quan đến công việc trong tương lai do thời gian làm việc kéo dài. Thật không may, chỉ có xterm và mlterm cũ mới đưa chúng ta đến ngưỡng ping kỳ diệu là 10 mili giây, điều này không thể chấp nhận được đối với nhiều người.
Các phép đo điểm chuẩn cũng cho thấy do sự phát triển của môi trường đồ họa Linux, các nhà phát triển đã phải thực hiện một số thỏa hiệp. Một số người dùng có thể muốn xem xét các trình quản lý cửa sổ thông thường vì chúng giúp giảm ping đáng kể. Thật không may, không thể đo độ trễ cho Wayland: chương trình Typometer mà tôi sử dụng được tạo ra cho mục đích mà Wayland được thiết kế để ngăn chặn: theo dõi các cửa sổ khác. Tôi hy vọng rằng tính năng tổng hợp của Wayland hoạt động tốt hơn X.org và tôi cũng hy vọng rằng trong tương lai ai đó sẽ tìm ra cách đo độ trễ trong môi trường này.
Nguồn: www.habr.com