Term.everything - Chạy mọi ứng dụng GUI trong terminal

• Một chương trình CLI cho Linux, cho phép chạy trực tiếp các ứng dụng GUI trong terminal
• Sử dụng trình tổng hợp Wayland do chính dự án tự xây dựng để chuyển đầu ra GUI vào terminal thay vì màn hình
• Có thể chạy cả trong môi trường ssh, và chạy được trình duyệt web, trình quản lý tệp, thậm chí cả game Doom ngay trong terminal
• Chất lượng đầu ra phụ thuộc vào độ phân giải terminal (số hàng·cột), và trên các terminal hỗ trợ hình ảnh như iTerm2·kitty còn hỗ trợ render ở độ phân giải đầy đủ
• Được phát triển dựa trên Typescript và bun, có kèm một phần mã C++, hiện mới chỉ hỗ trợ một số ứng dụng nhưng đang mở rộng với mục tiêu “Term everything❗”

---

Tầm quan trọng của dự án và ưu thế so sánh

• Khác với các trình xem tệp trong terminal hoặc công cụ xuất ảnh đơn giản trước đây, Term.everything có thể chạy “mọi” ứng dụng GUI ngay bên trong terminal
• Có thể sử dụng giao diện GUI ngay cả trong môi trường mạng bao gồm SSH, nên đặc biệt mạnh cho quản trị máy chủ và phát triển từ xa
• Tận dụng tối đa khả năng hiển thị hình ảnh của các terminal hiện đại như kitty, iTerm2, đồng thời cung cấp các tùy chọn cải thiện độ phân giải và tốc độ khung hình

Tổng quan

• Term.everything là một chương trình Linux CLI, nổi bật ở khả năng chạy trực tiếp các cửa sổ GUI trong terminal
• Trọng tâm là một trình tổng hợp dựa trên Wayland do dự án tự phát triển, render GUI vào terminal thay vì màn hình thông thường
• Hỗ trợ cả nền tảng x11 và Wayland, đồng thời có thể dùng từ xa qua ssh
• Số hàng/cột giới hạn của terminal ảnh hưởng đến chất lượng cửa sổ; tăng độ phân giải terminal có thể cải thiện chất lượng (nhưng có thể làm giảm hiệu năng)

Ví dụ sử dụng chính

• Chạy game: có thể chạy các game như Fontemon hoặc Doom (bản shareware episode) trong terminal
• Phát video: phát phim Wing It!, có thể điều chỉnh độ phân giải để cân bằng giữa tốc độ khung hình và chất lượng hình ảnh
• Chạy trình duyệt: trong môi trường iTerm2 + ssh, có thể kết nối vào Ubuntu và chạy Firefox
• Thay thế trình xem tệp: không cần phải tạo riêng trình xem tệp chỉ dành cho terminal, mà có thể dùng trực tiếp trình quản lý tệp GUI hiện có trong terminal
• Chạy đệ quy: chạy thêm một terminal khác bên trong terminal, kiểu "terminal in a terminal"

Nguyên lý hoạt động và thông tin phát triển

• Khái niệm cơ bản

  • Trước đây, để chương trình vẽ thứ gì đó lên màn hình, nó có thể ghi trực tiếp vào một vùng nhất định của RAM
  • Trong các hệ thống hiện đại, máy chủ hiển thị (Display Server) quản lý đầu vào/đầu ra, điều phối các thao tác nhập như chuột/bàn phím và xuất đồ họa/hình ảnh
  • Trong môi trường Linux, chủ yếu sử dụng giao thức Wayland hoặc X11, và Term.everything hoạt động dựa trên Wayland

• Giao thức Wayland

  • Wayland không phải bản thân máy chủ hiển thị, mà là một giao thức định nghĩa giao tiếp giữa máy chủ và chương trình
  • Chương trình gửi kết quả render trực tiếp của mình cho máy chủ hiển thị, và máy chủ sẽ xuất nó ra màn hình
  • Điểm quan trọng là mô hình render không bị áp đặt → chương trình có thể vẽ theo cách mà nó muốn
  • Nhờ đó, có thể gửi kết quả đầu ra đến nơi khác thay vì màn hình (ví dụ: terminal)

• Xử lý đầu ra của Term.everything

  • Nhận hình ảnh do Wayland client (ứng dụng GUI đang chạy) vẽ, rồi chuyển đổi thành đầu ra ký tự của terminal
  • Quá trình chuyển đổi:
    • 1. Nhận dữ liệu hình ảnh do client gửi tới
    • 2. Chuyển nó thành ký tự UTF-8 + mã escape ANSI
    • 3. Trong quá trình chuyển đổi, sử dụng thư viện chafa để ánh xạ pixel sang ký tự terminal
  • Đầu vào được chuyển tiếp tới Wayland client dưới dạng sự kiện bàn phím và chuột nhận qua stdin

• Triển khai thực tế

  • Ý tưởng cốt lõi khá đơn giản, nhưng việc hiện thực thực tế cần khoảng hơn mười nghìn dòng mã
  • Được viết bằng Typescript (dựa trên bun) và một phần C++, đồng thời đóng vai trò như một máy chủ hiển thị Wayland tùy biến
  • Có thể xem mã nguồn trong thư mục src/

• Khả năng mở rộng

  • Term.everything không chỉ hướng tới việc chạy GUI trong terminal đơn thuần
  • Với máy chủ hiển thị tùy biến dựa trên Wayland, còn có khả năng hiện thực nhiều ý tưởng thử nghiệm khác
  • Ví dụ: kết nối thiết bị xuất ra không phải terminal mà là một phương tiện hoàn toàn khác (ví dụ: máy in, tác phẩm nghệ thuật vật lý, v.v.)

[iolothebard]

Chồng chéo không cần thiết

[ifmkl]

Đúng là kiểu này mới thật sự geek chứ hehe

[hybridego]

Sao của tôi chỉ hiện logo rồi không chạy nhỉ??

[bus710]

Trước đây tôi dùng Synergy để điều khiển máy Mac cá nhân từ máy Mac của công ty. Giờ thì tôi đã thanh lý máy Mac cá nhân và chỉ dùng Linux, nên quy trình làm việc trở nên bất tiện hơn.

Nhưng nếu dùng công cụ này thì có nghĩa là tôi có thể truy cập desktop Linux cá nhân từ terminal trên máy Mac của công ty và thoải mái làm đủ thứ việc đúng không?

Có lẽ đội bảo mật sẽ không thích điều đó.

[coremaker]

Có lẽ vì tôi cũng là dân kỳ cựu rồi, nhưng cái này có thực sự cần thiết không?

[cgl00]

Có vẻ sẽ hữu ích khi thực hiện các thử nghiệm liên quan đến web trên server (thông qua localhost).

[coremaker]

Ý bạn là muốn xử lý trên máy cục bộ và kiểm thử trước khi triển khai đúng không?
Khi phải làm việc từ xa, khó truy cập mạng nội bộ nên ở trong một môi trường bị hạn chế...

[t7vonn]

Nếu mở iTerm bằng term.everything bên trong iTerm thì... có được không?

[GN⁺]

Ý kiến Hacker News

• Tôi thấy đây là một dự án vừa vô dụng vừa tuyệt vời, đứng ở ranh giới giữa lập trình và nghệ thuật, và tôi tin đây hẳn đã là một trải nghiệm học hỏi cực kỳ thú vị, thật sự muốn nói là làm quá tốt
  • Có lẽ cũng không vô dụng 100%, tôi nghĩ nó có thể hữu ích cho các ứng dụng chạy trong container Docker, bình thường vẫn có cách mở ứng dụng GUI trong container nhưng cách này có thể đơn giản hơn, dù vậy việc chạy ứng dụng GUI trong Docker thực ra cũng dễ hơn tưởng tượng, tôi dự định ngày mai sẽ thử theo hướng dẫn này và cũng tò mò không biết có chạy được trên Windows không
  • Khó giải thích vì sao dự án này lại khiến tôi vui đến vậy, nhưng dù có lẽ tôi sẽ không mấy khi dùng nó thật, cứ nghĩ đến là tôi lại nở một nụ cười ngốc nghếch
• Đây là kiểu dự án khiến người ta không còn biết giới hạn nằm ở đâu, thật sự rất ngầu và là thứ người ta muốn khoe mãi không thôi, tôi thấy quá ấn tượng và điều đó cũng khiến tôi suy nghĩ về cách nhóm mình nên triển khai VDI trong tương lai, nó như mang lại một ý nghĩa mới cho cụm từ ghost in the shell, mà tiện thể thì không biết có chạy được doom không
  • Nếu tò mò thì có thể xem cảnh chạy doom, do term.everything chỉ nhận đầu vào từ stdin nên tôi đã sửa vài dòng để nó hoạt động, mức tương thích với nhiều terminal khác nhau qua ssh khá cao
    1. Ánh xạ phím Control sang phím khác (vốn dĩ nó dùng để gửi signal)
    2. Phải điều chỉnh timeout đầu vào. Kiểu nhập dựa trên stdin chỉ nhận sự kiện keydown chứ không có keyup, nên phải đoán thời điểm người dùng nhả phím, thông thường có thể gửi keyup ngay lập tức nhưng với doom thì do xử lý key debounce nên phải chờ khoảng 50~100ms, trong game nếu muốn đi tới thì thường chỉ cần giữ phím mũi tên lên, còn với cách hiện tại thì phải bấm lặp lại nên hơi bất tiện, nhưng vẫn chạy được và chơi được
  • aaquake là một trò chơi đã từng chạy trong môi trường terminal ASCII từ trước cả dự án kiểu này
• Tôi nghĩ dự án này thật sự rất hay, cá nhân tôi thấy sẽ còn có nhiều trường hợp sử dụng thú vị hơn dựa trên Wayland, và tôi cũng quan tâm đến những dự án như greenfield
• Trước đây khi thấy dự án carbonyl chạy chromium trong terminal tôi đã rất phấn khích (xem tại đây), nhưng hiện tại nó không còn được bảo trì nữa, còn dự án lần này cho cảm giác như là một bước nâng cấp hơn nữa của ý tưởng đó, tôi thật lòng thấy đây là một kết quả rất ấn tượng
• Tôi nghĩ bash_completion cần phải được làm sao cho thật dễ dùng, thực tế viết nó khó hơn tưởng tượng nhiều, ngay cả việc copy-paste đơn thuần cũng phiền phức, các lập trình viên giỏi sẽ tạo ứng dụng tương thích tốt với bash_completion ngay từ đầu, ví dụ nếu đối số cốt lõi đầu tiên thân thiện với bash thì chỉ với cấu trúc mycli myfunc ... là có thể bấm tab một lần để thấy ngay toàn bộ tính năng, cũng không cần quảng bá tính năng mới, chỉ cần bỏ nó khỏi completion là có thể ngừng dùng tính năng một cách tự nhiên mà không làm hỏng các script cũ, cuối cùng thì nhờ có ai đó làm sẵn mà mọi thứ đều được dồn vào CLI
• Với những người như tôi, thỉnh thoảng phải truy cập trực tiếp desktop hoặc browser trên máy build để làm việc, thì VNC hay các kiểu chia sẻ desktop khác không thực tế hoặc có vấn đề về bảo mật, và tôi nghĩ dự án này sẽ rất hữu ích trong những tình huống như vậy
• Tôi nghĩ đây là một dự án thật sự dùng được, có vẻ khá ổn cho các tác vụ từ xa mang tính một lần, còn chuyện gắn vào một chương trình đang chạy từ xa rồi tách ra lại, hay phần mirror màn hình thì tôi chưa rõ, nhưng nếu có thể SSH vào desktop rồi điều khiển một client như Discord đang chạy sẵn thì sẽ rất tiện, nhân tiện tôi cũng muốn tìm hiểu thêm về các tính năng RDP liên quan đến chạy ứng dụng từ xa
  • Có lẽ bạn chỉ cần dùng một Discord client cho CLI, hoặc chạy một IRC client kết nối tới máy chủ Bitlbee cũng được
• Chắc tôi phải ghi chú lại điểm là <i>trong terminal</i>, tự nhắc mình rằng có lẽ cái này sẽ không hoạt động ở chế độ text mode
  • Nhưng chẳng phải ví dụ đầu tiên (ví dụ truyện tranh) là text mode sao
• Chúc dự án tiếp tục phát triển, mong là đừng bao giờ dừng lại
• Tôi thật sự thấy quá đỉnh! Chắc mỗi người sẽ có những trường hợp sử dụng độc đáo riêng, còn với tôi thì tôi rất mong chờ khả năng chạy VSCode trên iPad, hy vọng một ngày nào đó iPadOS cũng có thể được hỗ trợ
  • Tôi thì thường dùng code-server cho phát triển từ xa và thấy như vậy là đủ
  • Có các SSH client cho iPad nên tôi nghĩ là làm được, tôi định thử ngay bây giờ