Phỏng vấn Mitchell Hashimoto: Ghostty, Zig và bảo trì mã nguồn mở

• Mitchell Hashimoto, sau Vagrant, Terraform và Vault, hiện đang tạo ra Ghostty và Vouch, đồng thời hệ thống hóa các tiêu chuẩn của mình về terminal, Zig, bảo trì mã nguồn mở và chất lượng sản phẩm
• Ghostty khởi đầu như một dự án cá nhân để học lập trình GPU, lập trình hệ desktop/hệ một nút và Zig, rồi phát triển với mục tiêu trở thành một terminal native đa nền tảng nhanh và giàu tính năng
• Theo ông, terminal nên phát huy khả năng kết hợp, tự động hóa và mô hình bảo mật rõ ràng của các ứng dụng dựa trên văn bản, thay vì cố ôm hết mọi tính năng như trình duyệt; còn luồng byte phi cấu trúc của PTY vẫn là một giới hạn lớn
• Ông cho rằng người bảo trì mã nguồn mở không có nghĩa vụ với người dùng, nhưng để tạo ra phần mềm tốt thì không nên chỉ nhận nguyên từng yêu cầu riêng lẻ, mà cần giải quyết nhiều vấn đề bằng một tính năng nhất quán
• Những thay đổi lớn của Zig gây áp lực cho downstream, nhưng đang nâng chất lượng API và công cụ biên dịch; ông cũng đánh giá AI có thể giảm bớt công việc lặp lại khi xử lý thay đổi quy mô lớn, từ đó hạ gánh nặng tương thích ngược

---

Vì sao Ghostty ra đời

• Mitchell Hashimoto là người đã tạo ra Vagrant, Packer, Consul, Terraform, Vault, Nomad, Waypoint, và hiện đang phát triển Ghostty cùng Vouch
• Ghostty bắt đầu từ nhận thức rằng dù đã xây dựng ứng dụng CLI suốt khoảng 15 năm, ông vẫn chưa thực sự hiểu terminal emulator hoạt động như thế nào
• Sau khi rời Hashicorp, có ba lĩnh vực ông muốn quay lại khám phá
  • Lập trình GPU theo nghĩa trước làn sóng AI
  • Lập trình cho desktop/hệ một nút, khác với hệ phân tán
  • Sử dụng Zig
• Mục tiêu ban đầu chỉ là chạy được vim và compiler, để Ghostty có thể tự build chính nó, rồi sau đó bỏ đi
• Nhưng khi quan sát sâu hơn hệ sinh thái terminal, ông nhận thấy đang thiếu một công cụ vừa nhanh, vừa giàu tính năng, lại native và đa nền tảng
• Sau khi chia sẻ với bạn bè trên Discord, đã có người bắt đầu dùng hằng ngày; máy chủ Discord của Ghostty thực ra là từ một phòng chat nhóm bạn bè chuyển thành không gian riêng
• Vì cho rằng độ nhận biết công khai có thể tạo ra sự chú ý quá mức, dự án đã được vận hành khá lâu dưới dạng beta kín

Terminal nên mở rộng đến đâu

• Hashimoto phản đối hướng đẩy terminal thành một nền tảng ứng dụng khổng lồ bằng mọi giá
• Terminal có thể ôm thêm truy cập video, microphone hay layout phản hồi như trình duyệt hoặc Java runtime ngày trước, nhưng theo ông, trình duyệt, desktop và ứng dụng lưới đơn cách dựa trên văn bản mỗi loại đều có điểm mạnh riêng
• Ứng dụng dựa trên văn bản có thể được triển khai nhanh, dễ tương tác và cần có mô hình bảo mật rõ ràng
• Điểm mạnh của ứng dụng dựa trên terminal nằm ở khả năng kết hợp
  • TUI thì ít rõ hơn, nhưng đa số công cụ CLI đều có cơ chế vượt ra ngoài stdin/stdout để có thể dùng như một hàm
  • Triết lý UNIX “làm một việc thật tốt” là biểu hiện cực đoan của điều đó
  • Neovim và các công cụ AI đang ngày càng cung cấp nhiều cờ dòng lệnh hơn
• Ứng dụng terminal tốt hơn sẽ dẫn tới tự động hóa và khả năng viết script tốt hơn
• Tín hiệu in-band của PTY, tức luồng byte phi cấu trúc chứa cả escape sequence, vẫn là một vấn đề lớn
• Hệ sinh thái Nushell đang cố sửa điều này ở một tầng riêng, nhưng Hashimoto cho rằng cần có cải tiến căn cơ hơn
• Dù nhiều người không thích hệ sinh thái Microsoft, ông vẫn đánh giá PowerShell làm rất tốt ở khía cạnh dữ liệu có cấu trúc

Hình dung về API terminal phi legacy

• Khi nghĩ về một API terminal mới, Hashimoto tham khảo framework của các nền tảng ứng dụng lớn như trình duyệt, Emacs, Apple, Microsoft, Android hay máy chơi game
• Ông cho rằng nên khảo sát trước các tiền lệ đã tích lũy sẵn như DOM và JS API của web; AppKit, Cocoa, SwiftUI của Apple; Win32, WinUI của Windows; GTK, Qt trên Linux
• Chỉ riêng việc truy cập clipboard cũng cho thấy giao thức terminal lịch sử chủ yếu xoay quanh văn bản, trong khi desktop đã xử lý ảnh và nhiều MIME type từ rất lâu, nên cần đọc tài liệu clipboard của từng nền tảng
• Hiện ông vẫn chưa đưa giao thức tùy biến vào Ghostty

• API n-screen

  • Terminal hiện nay thường có hai loại màn hình là main screen và alt screen
  • main screen gần với shell và scrollback hơn, còn alternate screen gần với Neovim và đa số TUI hơn
  • Cấu trúc này hoạt động theo kiểu bật hoặc tắt một trong hai chế độ, thường chiếm toàn màn hình và làm mất scrollback
  • Hashimoto hình dung một API n-screen cho phép tạo và đổ nội dung vào số lượng màn hình không giới hạn ở nền
  • Mỗi màn hình có thể dùng kích thước lưới khác nhau và chồng lớp lên nhau; terminal emulator có thể xử lý xuống dòng, chọn vùng và định tuyến sự kiện chuột
  • Nếu một màn hình cụ thể được đánh dấu là cửa sổ độc lập, terminal emulator còn có thể render nó ngoài lưới
  • Ví dụ được ông nêu ra là có thể mở nhiều tab Neovim cùng lúc như các tab cửa sổ native

• Giao thức nút bấm

  • Giao thức chuột hiện tại chỉ nhận được sự kiện khi người dùng bấm vào ô lưới của màn hình hiện tại
  • Các mục lịch sử đã đi vào scrollback thì không thể nhận sự kiện click
  • Terminal hiện hỗ trợ giao thức hyperlink OSC 8
  • Hashimoto hình dung một giao thức nút bấm tương tự OSC 8, gửi về chương trình một thông điệp đã chỉ định khi được click
  • Ví dụ, một nút có ID open_profile có thể vẫn được đăng ký ngay cả khi người dùng cuộn ngược lên phần lịch sử
  • Tính năng này ảnh hưởng tới các ứng dụng main screen có scrollback, và gắn với vấn đề ở các ứng dụng main screen như Claude Code: khi liên kết mở file hoặc liên kết nội bộ ứng dụng bị đẩy vào lịch sử thì chúng không còn hoạt động

Sự thiếu vắng tiêu chuẩn và bảo trì mã nguồn mở

• Hashimoto từng thử thay toàn bộ giao thức PTY bằng Wayland, nhưng rồi bỏ ý tưởng đó
• Ông cho rằng terminal có thể được nhìn như một windowing server quản lý cửa sổ và widget cửa sổ, còn Wayland là một giao thức tốt để giải quyết bài toán desktop cục bộ và render cửa sổ
• Một trong các vấn đề của terminal là không còn tổ chức tiêu chuẩn hóa nào nữa
• Các đặc tả cũ vẫn còn, nhưng việc tiêu chuẩn hóa suốt 20 năm qua thực chất diễn ra theo hướng terminal phổ biến nhất đang làm gì
• Kết quả là nhiều tính năng bị trộn lẫn, và không có chủ thể nào đủ sức thúc đẩy một tầm nhìn có gu rõ ràng
• Ông chưa chốt con đường sắp tới; một khả năng khác là tạo ra không gian ứng dụng dựa trên văn bản mới, không phải terminal, rồi đặt một lớp chuyển dịch terminal để hỗ trợ ứng dụng legacy

• Cân bằng giữa yêu cầu người dùng và tầm nhìn lớn

  • Hashimoto từ lâu đã công khai nói rằng người bảo trì mã nguồn mở có 0 nghĩa vụ với người dùng
  • Dòng đầu tiên của giấy phép mã nguồn mở là “as is, no warranty”, và theo ông, đổi lấy việc nhận phần mềm miễn phí, người dùng không có quyền đòi hỏi
  • Đồng thời, vì muốn tạo ra phần mềm tốt, ông vẫn cảm thấy có trách nhiệm sửa vấn đề và làm phần mềm tốt hơn
  • Có ngày ông xem issue để sửa vấn đề của người khác; cũng có ngày ông không nhìn issue, thảo luận hay PR mà chỉ tập trung vào điều mình muốn làm
  • Nếu ngày nào cũng chỉ xử lý issue của người dùng, phần mềm sẽ ổn định nhưng trì trệ; còn nếu nhận mọi PR, phần mềm có thể thay đổi nhưng sẽ mất tầm nhìn
  • Phần lớn đóng góp chỉ giải quyết vấn đề rất riêng của một cá nhân; nếu nhận hết, mã nguồn sẽ chất đống thành núi
  • Ngược lại, nếu hiểu vấn đề đủ sâu, có thể giải quyết đồng thời nhiều yêu cầu tính năng bằng một hệ thống duyên dáng duy nhất
  • Trong video thiết kế tính năng, ông nêu ví dụ đã đóng 3-4 yêu cầu tính năng riêng lẻ và giải quyết tất cả cùng lúc bằng một tính năng khác

• Phân biệt giàu tính năng và phình to

  • Tìm kiếm, một trong những tính năng được yêu cầu nhiều nhất ở Ghostty, đã được triển khai và phát hành
  • Một số người dùng chỉ trích rằng tính năng tìm kiếm làm hỏng tinh thần tối giản của Ghostty và khiến nó phình to, nhưng Hashimoto đáp lại rằng ông quảng bá Ghostty là một terminal giàu tính năng
  • Ông phân biệt rõ giữa giàu tính năng và phình to
  • Tính năng tìm kiếm có chiếm dung lượng đĩa và RAM khi nạp, nhưng được thiết kế để nếu không dùng thì sẽ không có đoạn mã nào chạy
  • Vì vậy, theo ông, đây là tính năng không có chi phí thực thi đối với người không dùng đến
  • Ghostty hướng tới một terminal có thể được người dùng tùy biến theo nhu cầu, vẫn hoạt động ở trạng thái mặc định, và ẩn các tính năng cho tới khi người dùng cần hoặc đi tìm chúng
  • Với yêu cầu giữ lại cờ loại bỏ tính năng, ông cho rằng việc người bảo trì phải quản lý cờ đó cũng là cùng một loại gánh nặng như việc người dùng tự duy trì một fork đã loại bỏ tính năng

Quyền của mã nguồn mở, thay đổi của Zig và chất lượng API

• Hashimoto tin rằng nên có nhiều fork cá nhân và fork được duy trì hơn nữa
• Theo ông, mã nguồn mở dựa trên đầu tư mạo hiểm đã tạo ra một thế hệ kỳ vọng các dự án được trau chuốt kỹ, có website, có đội hỗ trợ trả phí và hỗ trợ qua Slack hay Discord
• Nhưng cốt lõi của mã nguồn mở không phải bảo đảm sản phẩm, mà là tự do và quyền hạn
  • Dùng theo ý muốn
  • Chỉnh sửa
  • Fork
• Sự ổn định hay nghĩa vụ bảo trì không nằm trong các quyền đó
• Ông nói không thể chỉ đổ lỗi cho người bảo trì nếu có commit đưa lỗ hổng bảo mật vào, vì người dùng cũng có trách nhiệm khi không tự xem xét commit đó
• Nếu muốn bảo đảm mạnh hơn và quyền được quy trách nhiệm cho ai đó, người dùng nên trả tiền cho phần mềm để hình thành quan hệ vendor-khách hàng
• Trong dự án cá nhân, ông thậm chí có thể không merge PR sửa lỗi mà bản thân chưa từng gặp
  • Bởi merge đồng nghĩa với việc cam kết bảo trì đoạn mã đó mãi về sau

• Cách nhìn về Zig

  • Hashimoto nói rằng khi chọn Zig, ông đã biết mình chấp nhận điều gì; qua việc vá compiler, ông cũng hiểu thêm cộng đồng, văn hóa và triết lý của Zig
  • Thay đổi I/O vẫn chưa bắt đầu được ông dự đoán sẽ là một trong những công việc khó nhất của Zig
  • Dù Zig đang ngày càng phổ biến, Andrew vẫn không lùi bước trước những thay đổi mà ông cho là cần thiết; với tư cách người dùng downstream, Hashimoto đánh giá cao điều đó
  • Zig 0.15 đã thay đổi interface writer, ảnh hưởng tới gần như mọi đoạn mã có xuất dữ liệu, nhưng ông cho rằng chính API lại trở nên tốt hơn nhiều
  • Zig đang tập trung vào công cụ biên dịch, thậm chí từng loại bỏ một số tính năng ngôn ngữ để tăng tốc độ biên dịch
  • Toàn bộ terminal lib-ghostty có thể được build ngay lập tức, nhưng theo ông, Andrew còn cho rằng khoảng thời gian tính bằng mili giây đó vẫn là quá chậm
  • Zig 1.0 rồi sẽ đến vào một lúc nào đó, nhưng theo ông vẫn còn cách vài năm nữa
  • AI có thể làm giảm nỗi đau downstream do các thay đổi ngôn ngữ gây ra
  • Khi cho AI xem cách áp dụng thay đổi trong nhiều ngữ cảnh rồi bảo nó làm phần còn lại, khoảng 90% của một diff lớn đã được xử lý tự động
  • Nếu có thể mô tả cách đi từ trạng thái A sang trạng thái B, điều đó gợi ra một tương lai nơi ý nghĩa của tương thích ngược giảm đi
  • Dù điều này mỉa mai với lập trường chống AI rất mạnh của Zig, ông vẫn cho rằng AI làm dịu bớt nỗi đau mà thay đổi gây ra cho người dùng downstream

• Thư viện và thiết kế API

  • Cách cụ thể nhất để học thiết kế thư viện tốt là trực tiếp dùng thật nhiều thư viện từ nhiều cộng đồng khác nhau
  • Cũng như học một ngôn ngữ lập trình mà bạn có thể không dùng trong công việc thực tế, việc dùng thư viện từ nhiều hệ sinh thái khác nhau sẽ mở rộng góc nhìn
  • Thời đại học, ông từng làm các sản phẩm đồ chơi bằng Prolog, Haskell, Clojure và Java để tìm hiểu build system, khả năng sử dụng, thư viện, web framework, web server và app server của từng hệ sinh thái
  • Theo ông, văn hóa của mỗi hệ sinh thái thấm vào cách thư viện và framework tách biệt mối quan tâm cũng như hình dạng của API
  • Ông lấy ví dụ từng thử mang builder pattern vốn dùng lâu năm trong Java sang Ruby và thấy kết quả ổn, như một trường hợp chuyển giao khái niệm
  • Với Docker, ông cho rằng nhiều yếu tố của triển khai và runtime bị trộn vào luồng phát triển; còn Vagrant thì cố ý dùng danh từ, CLI và cấu hình tập trung trực tiếp vào phát triển

• Thế tiến thoái lưỡng nan của người làm công cụ và stack công nghệ

  • Hashimoto nói mình là người làm công cụ cả đời và tin vào thế tiến thoái lưỡng nan của người làm công cụ
  • Tức là bạn hiểu rất sâu một vấn đề để tạo ra công cụ lý tưởng, nhưng khi công cụ đó trở nên phổ biến, bạn có thể không còn là người dùng thực tế nữa mà chỉ là một người làm công cụ đã mất độ bám với thực tế
  • Dù bản thân dùng terminal mỗi ngày, ông thừa nhận mình chưa phát triển TUI đủ nhiều, và đang phụ thuộc vào những người bảo trì như rockorager, người vừa duy trì nhiều email/IRC client vừa viết cả đặc tả
  • Với stack công nghệ hiện tại, thái độ của ông chỉ ở mức “ổn thôi”
  • Ông thấy frontend, TypeScript và cộng đồng kiểu React có nhiều điểm tốt, nhưng thay đổi quá nhiều, độ phức tạp quá cao và các lớp trừu tượng không rõ ràng
  • Ông nói ở nhiều lĩnh vực, độ phức tạp đã tăng phi tuyến tính, giống như quá trình đi từ HTTP/1 sang HTTP/2 và HTTP/3
  • Ngành công nghiệp đang đi quá nhanh, làm những thứ vốn có thể đơn giản trở nên phức tạp, và AI cùng các công cụ liên quan đang đẩy nhanh xu hướng này

Nguyên tắc, văn hóa, chất lượng và học tập

• Ông nói các tài liệu nguyên tắc của Hashicorp hay cách phát triển Ghostty đều là sự phản chiếu của chính cá nhân mình, nên việc thực hành mỗi ngày trở nên dễ dàng
• Nếu đặt ra những nguyên tắc khác với bản thân, rất khó biến chúng thành hành động thực tế, giống như các lời hứa đầu năm mới
• Ghostty coi trọng đồng thời phần lõi đa nền tảng và GUI native
  • Phần lõi là đa nền tảng
  • GUI thì không cố chấp đa nền tảng mà ưu tiên cách làm native riêng của từng nền tảng
• Theo ông, dự án mã nguồn mở và Internet nên là tập hợp của nhiều bộ lạc khác nhau
• Ông không thích việc các ngôn ngữ lập trình trở thành một kiểu mẫu số chung tối thiểu với mọi tính năng mà ai cũng muốn; theo ông, chính ràng buộc tạo ra sáng tạo và văn hóa
• Ông nói thích ngôn ngữ và triết lý của Rust, nhưng không thích văn hóa Rust; đồng thời nhấn mạnh điều đó không có nghĩa là người trong cộng đồng Rust là người xấu
• Zig, theo ông, có lập trường rất rõ và gây phân cực từ công nghệ, cách quản lý cộng đồng, gọi vốn, PR, bài blog cho tới cách phát ngôn; và ông tôn trọng sự kỳ lạ đó nên tiếp tục hỗ trợ tài chính và sử dụng nó
• Để phát hành nhanh mà vẫn đảm bảo chất lượng, cần hiểu không chỉ vấn đề cụ thể của khách hàng mà còn cả bối cảnh khiến người dùng đi đến vấn đề đó và các vấn đề thượng nguồn
• Ông nói không biết cách giải quyết điều này ở quy mô doanh nghiệp, nhưng cá nhân thì ra quyết định với tư cách một người dùng lớn của chính phần mềm mình tạo ra
• Với AI, ông cho rằng có thể dùng thô để làm demo hay kiểm tra định hướng, nhưng mã đem đi phát hành thì phải được đọc, hiểu và phát hành với chất lượng tử tế
• Khi học C, điều quan trọng hơn bản thân ngôn ngữ là hiểu máy tính hoạt động như thế nào
  • Cần hiểu CPU scheduling, bộ nhớ, các tầng cache, file system, đĩa và cách truy cập file
  • Khi làm việc ngay trên tầng syscall bằng C, Zig hay Rust, sẽ dễ hiểu điều gì đang diễn ra hơn
  • API mở file trong Python, JavaScript hay Ruby đã trừu tượng hóa rất nhiều chi tiết
  • Ngay cả hàm trong standard library cũng không nên coi là hiển nhiên; vì đó là mã do ai đó viết, nên ông khuyên hãy tự đọc và đào sâu để hiểu nó hoạt động thế nào

[unsure4000]

Đăng gần như cùng thời điểm mà bầu không khí khác nhau quá nên thấy thú vị ghê haha
Suy nghĩ của tôi về việc Bun viết lại bằng Rust

[sea715]

• Phần lớn tranh luận không xoay quanh ý tưởng mà là cái tôi
  Haha...

[ffdd270]

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk

[GN⁺]

Ý kiến trên Lobste.rs

• Đây là một cuộc phỏng vấn rất hay, và câu tôi thích nhất là: “Không đồng ý với mọi thứ, nhưng tôi thật sự tôn trọng việc dám kỳ quặc một cách đường hoàng”
  Mong là sẽ có nhiều thái độ như vậy hơn

• Nếu nói về những tiền lệ đi trước và sự tiến hóa của terminal thì ít nhất cũng nên nhắc đến Arcan và cat9
  https://arcan-fe.com/2022/04/…

• Đoạn “PowerShell xử lý tốt dữ liệu có cấu trúc” làm tôi nhớ tới câu trả lời này của Jörg W Mittag
  Nếu dùng đối số có kiểu, thì PowerShell sẽ lo toàn bộ phần parsing
  Viễn cảnh tab của Neovim đồng thời mở thành tab cửa sổ native cũng thật sự rất tuyệt
  Làm việc ngay phía trên tầng system call như với C, Zig, Rust giúp ích rất nhiều trong việc hiểu điều gì đang xảy ra
  Quá trình bóc tách các lớp trừu tượng giữa máy và lập trình viên để chạm tới tầng nền tảng vừa thú vị, vừa giúp ta đến gần bản chất của vấn đề hơn
  Thư viện chuẩn thường nhắm tới tính di động nên chứa mẫu số chung nhỏ nhất của các tính năng hệ điều hành, nhưng khi có thể tận dụng nền tảng tối đa thì việc lập trình trở nên vui hơn rất nhiều
  Tôi rất tôn trọng thái độ cho rằng ngay cả hàm trong thư viện chuẩn cũng là code do ai đó viết ra, nên đừng xem là hiển nhiên mà hãy đọc nó
  Tôi cũng muốn biết thêm về chương trình tài trợ của Ghostty. Có vẻ nó đã được pháp nhân hóa theo dạng phi lợi nhuận, nên tôi tò mò không biết mức độ thành công và khả năng tự chủ của nó ra sao

• PowerShell trên Windows có ưu điểm là hoàn toàn kiểu nội tại theo định nghĩa này, nhưng vì được xây dựng trên .NET framework và có thể truy cập, tương tác với gần như mọi Windows API nên trên thực tế không bị giới hạn nhiều
  UNIX theo thiết kế là kiểu ngoại tại, còn câu trả lời có cấu trúc của Nushell, theo cách tôi hiểu, là kiểu nội tại nghiêm ngặt nên kém mở rộng
  Oils đặt cược vào json hoặc phần mở rộng riêng là json8 để tương tác có cấu trúc theo kiểu external, nhưng cả hai vẫn có cảm giác khá hạn chế so với PowerShell
  Tôi vẫn nghĩ hay là mọi người cùng thống nhất chỉ gửi thứ gì đó như msgpack qua stdout và biến mọi terminal thành trình xem msgpack. Chắc phải làm cả kiến nghị thêm serialize/deserialize qua pipe vào libc mất
  Không chỉ cơ quan tiêu chuẩn hóa terminal đã biến mất, mà thế giới shell xét theo tiêu chuẩn production cũng gần như không có đổi mới nào
  Bash vẫn đang thêm những tính năng mà Kornshell đã có từ trước, shell Unix có quá nhiều cạm bẫy mà chẳng ai biết cách loại bỏ, còn POSIX thì gần như đứng yên
  Tôi vẫn giữ giấc mơ rằng Oils hay Nushell sẽ được các distro lớn chấp nhận để mọi người nhận ra đổi mới trong lĩnh vực này là điều tốt
  Dù vậy, kitty rõ ràng đã khơi thông dòng chảy trong mảng terminal, và dù còn thiếu phối hợp thì ít nhất chúng ta cũng đã tới giai đoạn có đổi mới diễn ra

• Tôi ngày càng tôn trọng cách Mitchell bình tĩnh đánh giá mặt tích cực và tiêu cực
  Anh ấy tạo ra một terminal tuyệt vời và yêu thích giao diện terminal, nhưng không đồng ý với việc terminal phải làm mọi thứ hay bị đẩy đến cực đoan
  Anh ấy rất quan tâm tới ngôn ngữ lập trình và cộng đồng, muốn mỗi ngôn ngữ có bản sắc riêng, nhưng cũng hiểu rằng ngôn ngữ rốt cuộc chỉ là phương tiện cho mục đích, và sự hiểu biết về nền tảng bên dưới mới quan trọng hơn
  Anh ấy thừa nhận bản thân không thích cộng đồng Rust, nhưng cũng không hạ thấp những người cảm thấy khác
  Thật ấn tượng với một thái độ gần như Thiền: nhìn Internet như tập hợp của nhiều bộ lạc, nhưng không sa vào chủ nghĩa bộ lạc hay việc đi tìm “bộ lạc chân chính duy nhất”

• Tôi đồng ý với ý kiến rằng cần có nhiều fork cá nhân/bảo trì hơn, nhưng không rõ nên khuyến khích bằng cách nào
  Ở phía thấp hơn của phổ entitlement, có thể người ta không quan tâm tới các yếu tố doanh nghiệp như hợp đồng hỗ trợ trả phí, mà chỉ muốn sự tiện lợi là có thể cài ngay từ package manager họ thích
  Cần tìm cách giảm bớt ma sát ban đầu khi chuyển từ brew install hay apt install sang giai đoạn phải xử lý repository đã clone và công cụ build
  Compiler nhanh hơn có thể sẽ hữu ích
  Tuy vậy, với phần mềm nhạy cảm về bảo mật thì việc người dùng không sửa đổi quá nhiều đôi khi lại có lợi, nên chính sự ma sát đó đôi khi cũng là một tính năng

• Tôi rất đồng tình rằng UI hiện đại cần một thứ gì đó nằm ở khoảng giữa n-screen và đặc tả nút bấm
  Có lẽ chỉ cần gọi đó là lớp ngữ nghĩa
  Nếu có lớp này thì các công cụ dạng agent, công cụ màn hình chính, khả năng tiếp cận, widget và control có thể kết hợp được đều sẽ khả thi
  n-screen và button rốt cuộc trông giống như hai biên trái-phải của mức độ có thể biểu đạt bao nhiêu nội dung
  Lý tưởng nhất là lớp ngữ nghĩa này cũng nên mang theo các thứ như multi-cursor, word wrapping theo từ thay vì theo ký tự, overlay (z-index, cell blending, v.v.)