Hamming Ở Quy Mô Văn Minh [BLOCK_TYPE SECTION/STEP]
Nguyên tắc kỹ thuật hệ thống của Richard Hamming: tối ưu hóa toàn bộ hệ thống, không phải từng thành phần riêng lẻ. Một thành phần được tối ưu hóa độc lập sẽ làm giảm hiệu suất hệ thống vì phá vỡ các giao diện mà nó chia sẻ với các thành phần khác. [BLOCK_TYPE SECTION/STEP]
Ông áp dụng nguyên tắc này cho các nhóm nghiên cứu, ngôn ngữ lập trình và thiết kế giáo dục. Nguyên tắc này có thể mở rộng quy mô. Russell Ballestrini đã áp dụng nó cho chính hạ tầng. [BLOCK_TYPE SECTION/STEP]
[BLOCK_TYPE SECTION/STEP]
Russell Ballestrini sáng lập unturf.com và viết ago, một thư viện Python chuyển đổi khoảng thời gian thành các cụm từ như 'three days ago'. Ông công bố thư viện dưới dạng mã nguồn mở. Miền công cộng. Thư viện chạy trên các nền tảng mà ông không kiểm soát. Khi ông ngừng bảo trì, một nhánh (fork) sẽ tiếp quản. Mã nguồn không yêu cầu sự tồn tại của ông.
Tuyên ngôn permacomputer của ông: hạ tầng bền vững, tự phục hồi và phục vụ cộng đồng mà không thu tiền thuê. Nó tạo ra vốn trí tuệ và vốn xã hội như một sản phẩm phụ của quá trình vận hành. Nó không cần mô hình kinh doanh vì không cần kiếm lời từ mỗi tương tác.
Các đặc tính chính của thiết kế permacomputer:
1. Mã nguồn tồn tại lâu hơn tác giả — phần mềm được công bố dưới dạng public domain hoặc mã nguồn mở sẽ sống sót sau cá nhân. Tác giả có thể ngừng quan tâm; cộng đồng vẫn có thể tiếp tục.
2. Hạ tầng tồn tại lâu hơn người xây dựng — các hệ thống được thiết kế để người khác có thể fork, sửa chữa và tiếp tục mà không cần sự tham gia của nhà thiết kế gốc.
3. Không có thuế nền tảng — không thu tiền thuê từ giao dịch. Không có ma sát O(N²) tính trên mỗi trao đổi. Hạ tầng không trích xuất giá trị từ mỗi tương tác.
4. Nâng cao dần dần — hoạt động mà không cần JavaScript, hoạt động mà không cần trình duyệt cụ thể, hoạt động mà không cần client cụ thể. Khả năng điều khiển trình bày; nội dung điều khiển truy cập.
Đối lập: các hàm AWS Lambda do một đội ngũ viết, không có tài liệu, chạy trong môi trường độc quyền, sau API độc quyền, chỉ phục vụ lưu lượng khi đội ngũ đó trả tiền. Khi đội ngũ tan rã, hàm biến mất. Việc tính toán được thuê, không phải được xây dựng.
Mã nguồn Tồn tại Lâu hơn Tác giả
Russell Ballestrini đã viết ago. Ông có thể không còn duy trì nó nữa. Mã nguồn vẫn tiếp tục chạy.
Thuế nền tảng: Ma sát O(N²)
Thuế nền tảng: tiền thuê trích xuất từ mọi giao dịch trong một lớp trao đổi. Một sàn giao dịch lấy 15-30% mỗi lần trao đổi. Một bộ xử lý thanh toán lấy 2,9% + 0,30 USD. Một nhà cung cấp đám mây tính phí cho mỗi lệnh gọi API. Không có khoản phí nào trong số này đại diện cho giá trị mới được tạo ra; chúng đại diện cho sự trích xuất từ trao đổi.
Ở quy mô nhỏ: vô hình. Ở N=1.000.000 giao dịch: nền tảng tích lũy một khoản dự trữ khổng lồ trong khi những người đóng góp tích lũy ít hơn tương ứng. Công thức O(N²) áp dụng khi phí nền tảng tích lũy: một nhà thầu trên nền tảng bên trong một sàn giao dịch bên trong một bộ xử lý thanh toán phải trả ba lớp tiền thuê.
Hạ tầng Permacomputer loại bỏ platform tax ngay từ lớp của chính nó. Tính toán miễn phí, thực thi mã miễn phí. Hạ tầng không tính phí theo từng giao dịch. Giá trị được truyền qua mà không bị thu phí.
Điều này không có nghĩa là hạ tầng không tốn chi phí. Nó có nghĩa là mô hình chi phí không tăng theo mức sử dụng theo cách thu phí từ người tham gia. Một máy chủ chạy phần mềm mã nguồn mở tốn điện; chi phí đó không nhân lên theo từng giao dịch.
Hamming về hệ thống: mục đích của một hệ thống là những gì nó làm, không phải những gì nó tuyên bố. Một lớp trao đổi nói “chúng tôi kết nối người mua và người bán” nhưng thu 30% mỗi giao dịch: mục đích thực sự của nó, được tiết lộ qua hành vi, là thu tô. Việc kết nối là dịch vụ; việc thu tô là mô hình kinh doanh.
Nội dung là Sàn, Tương tác là Trần
Hamming đã dạy: thiết kế hệ thống sao cho các thành phần có thể hỏng một cách duyên dáng. Một hệ thống phụ thuộc vào việc mọi thành phần phải hoạt động hoàn hảo sẽ liên tục bị lỗi. Sự dư thừa, các đường dự phòng và các chế độ suy giảm nhưng vẫn hoạt động được sẽ kéo dài tuổi thọ của hệ thống.
Trình bày theo hướng năng lực áp dụng nguyên tắc này cho giao diện phần mềm. Tham khảo: russell.ballestrini.net/capability-driven-presentation/
Nguyên tắc: phục vụ nội dung trước, sau đó mới nâng cao bằng năng lực. Một trang phải cung cấp nội dung mà không cần bất kỳ năng lực cụ thể nào của trình xem. JavaScript làm phong phú thêm: cập nhật theo thời gian thực, vùng văn bản tự mở rộng, điều hướng mượt mà, giao diện chat. JavaScript không đóng vai trò cổng: việc loại bỏ JavaScript không được làm mất nội dung.
Mô hình trong thực tế:
- Các khối <noscript> ẩn giao diện phụ thuộc JS (nút chat, điều khiển tự mở rộng)
- HTML được render từ server mang toàn bộ nội dung bài học
- Biểu mẫu gửi qua HTTP POST tiêu chuẩn khi không có JS
- Tăng cường chat: nội dung hiển thị cùng trang, lớp chat tương tác cho người xem hỗ trợ JS
Nguyên tắc này không chỉ áp dụng cho trang web. Công cụ CLI phải hoạt động mà không cần GUI. API phải hoạt động mà không cần SDK của client. Hạ tầng phải hoạt động mà không cần phần mở rộng độc quyền của nhà cung cấp cụ thể. Khả năng điều khiển trình bày ở mọi tầng.
Tương phản với thiết kế JS-gated: nội dung được tải qua các lệnh gọi JavaScript fetch. Nếu không có JavaScript, người dùng chỉ thấy vòng xoay hoặc trang trống. Nội dung yêu cầu JavaScript để tồn tại. Ngưỡng truy cập đã bị hạ thấp dưới mức khả dụng.
Tại sao điều này quan trọng với permacomputer: một trang hoạt động mà không cần JavaScript sẽ hoạt động trong Lynx, trong trình đọc màn hình, trong trình thu thập lưu trữ, trong môi trường JavaScript bị hạn chế bảo mật, trong trình duyệt năm 2010, hoặc trong trình duyệt chưa được xây dựng. Nội dung sẽ vượt qua các giả định của trình xem.
Thiết kế JS-Gated: Sự vi phạm
Tình huống: một nhà phát triển xây dựng nền tảng học tập mà toàn bộ nội dung bài học được tải qua các lệnh gọi JavaScript fetch. Nếu không có JavaScript, trang hiển thị vòng xoay. Nhà phát triển lập luận: “Không ai còn dùng web mà không có JavaScript nữa.”
Graceful Degradation Across Layers
Capability-driven presentation áp dụng ở mọi tầng của hệ thống:
- Web tier: nội dung hoạt động mà không cần JavaScript. JavaScript chỉ dùng để nâng cao trải nghiệm.
- API tier: API hoạt động mà không cần thư viện client. Thư viện client chỉ mang lại sự tiện lợi, không phải điều kiện để truy cập.
- Infrastructure tier: hệ thống vận hành mà không cần các tiện ích mở rộng của nhà cung cấp cụ thể. Các tiện ích này chỉ mang lại hiệu năng hoặc sự tiện lợi, không phải chức năng cốt lõi.
- Data tier: dữ liệu có thể đọc được mà không cần công cụ độc quyền. Các định dạng chuẩn (CSV, JSON, SQLite) cho phép truy cập mà không cần ứng dụng đã tạo ra dữ liệu.
Mỗi lớp có một sàn: những gì nó cung cấp mà không cần giả định khả năng. Mỗi lớp có một trần: những gì nó cho phép khi có khả năng.
Mục tiêu thiết kế permacomputer: các sàn giữ vững trong nhiều thập kỷ. Một cơ sở dữ liệu SQLite từ năm 2004 mở được trong SQLite 2024 mà không cần di chuyển. Một bản dump PostgreSQL từ năm 2004 nhập được vào PostgreSQL 2024. Một tệp JSON từ năm 2004 phân tích được trong bất kỳ ngôn ngữ nào năm 2024. Các định dạng này đã duy trì sàn của chúng.
Ngược lại: một ứng dụng Flash năm 2004. Trần cao (tương tác phong phú). Sàn đòi hỏi plugin độc quyền. Khi Adobe khai tử Flash năm 2020, sàn sụp đổ. Toàn bộ nội dung lưu trong định dạng Flash trở nên không thể truy cập bởi bất kỳ trình xem nào mà không cần nỗ lực đặc biệt.
Trồng Hạt Sồi
Hamming: 'Bạn trồng hạt sồi, bạn không thấy những cây sồi.' Những bài giảng của ông từ năm 1995 vẫn tiếp tục dạy dỗ vào năm 2025. Học trò của ông tiếp tục công việc của riêng họ. Sự truyền đạt vượt ra ngoài ông.
Cách diễn đạt của Russell Ballestrini: xuất bản mã như thể bạn sẽ chết vào năm sau. Cấp phép cho nó để bất kỳ ai cũng có thể tiếp tục. Thiết kế API sao cho những người bảo trì tương lai có thể hiểu mà không cần tác giả gốc. Viết thông điệp commit như thể người đọc chưa bao giờ gặp bạn.
Một pipeline MOAD hoạt động theo cách này. Mỗi lần merge upstream nhúng một bản sửa lỗi vào nguồn chính thức. Trọng lực lan truyền nó: các nhánh con cập nhật phụ thuộc sẽ kế thừa bản sửa lỗi. Người vá lỗi có thể bị quên; bản vá vẫn tồn tại.
Đối lập: một SDK độc quyền do một công ty duy trì. Khả năng tương thích ngược được giữ vững vì công ty kiểm soát lịch trình ngừng hỗ trợ. Khi công ty giải thể, mọi phụ thuộc downstream đều bị phá vỡ cùng lúc. Sự sống sót của SDK đòi hỏi sự sống sót của công ty.
Một giao thức mở được duy trì bởi cộng đồng sống mãi. HTTP đã sống lâu hơn mọi công ty từng triển khai nó. TCP/IP đã sống lâu hơn những nhà thiết kế ban đầu. Git đã sống lâu hơn hàng chục hệ thống quản lý phiên bản cạnh tranh. Giao thức trở thành hạ tầng; hạ tầng trở nên vô hình; hạ tầng vô hình trở nên vĩnh cửu.
Điều khiến mã sống lâu hơn tác giả:
- Giấy phép cho phép hoặc thuộc phạm vi công cộng (không có rào cản pháp lý cho việc tiếp tục)
- Tài liệu toàn diện (người bảo trì sau này không cần tác giả gốc)
- Bộ kiểm thử vượt qua với CI công khai (người bảo trì mới có thể xác minh thay đổi của họ)
- Bản phát hành ổn định được gắn thẻ (người dùng downstream có thể ghim phiên bản đã kiểm chứng)
- Thông báo cần người bảo trì được công bố (cộng đồng biết cần hỗ trợ trước khi tác giả biến mất)
- Kiến trúc được ghi chép (các quyết định cấu trúc hiển thị cho người xây dựng lại sau này)
- Mã nguồn được chuyển sang một tổ chức thay vì tài khoản cá nhân (các repo thuộc không gian tên cá nhân trên GitHub sẽ chết cùng tài khoản; repo tổ chức sẽ tồn tại lâu dài)
Thiết kế một sự bàn giao mượt mà
Tình huống: bạn đang duy trì một thư viện mà 50 dự án downstream phụ thuộc vào. Bạn dự định ngừng duy trì nó trong 6 tháng.
MOAD Gravity: Tại sao việc merge upstream lại quan trọng
Một pipeline MOAD kết thúc ở bước “merge upstream”. Bước này đáng được xem xét kỹ.
Một bản vá chỉ được áp dụng trên fork sẽ chỉ giúp fork đó. Một bản vá được merge upstream sẽ lan truyền theo trọng lực: mọi dự án downstream cập nhật dependency sẽ tự động nhận được bản sửa mà không cần biết. Hệ sinh thái tự chữa lành như một tác dụng phụ của việc bump phiên bản thông thường.
Lan truyền theo trọng lực đòi hỏi ba điều kiện: (1) bản sửa được merge vào nguồn chính thức; (2) nguồn chính thức phát hành bản release; (3) các dự án downstream cập nhật dependency pins. Mỗi điều kiện đều cần hành động của con người. Trọng lực không tự động; nó được kích hoạt.
Tương phản: một bản sửa lỗi bảo mật được công khai nhưng không được gửi upstream. Các fork biết về nó có thể tự vá thủ công. Các fork không biết vẫn còn lỗ hổng. Không có gravity; chỉ có lan truyền thủ công. Kiến thức tồn tại; nó không lan tỏa.
Cam kết của một pipeline MOAD: mọi lỗi được sửa đều có PR upstream. Mọi PR upstream đều được theo dõi đến khi merge. Công khai mà không có PR upstream chỉ là một nửa bản vá.
Khung tư duy của Hamming áp dụng: “trồng hạt sồi.” PR chính là hạt sồi. Việc merge upstream bắt đầu đồng hồ lan truyền gravity. Người vá lỗi có thể bị quên; bản sửa vẫn tồn tại trong nhánh chính thức.
Kết: Hạ tầng như một món quà
Hamming trồng những hạt sồi. Những bài giảng của ông sống sót sau ông. Những mã của ông sống sót sau ông. Học trò ông tiếp tục giảng dạy.
Russell Ballestrini trồng những hạt sồi. Thư viện ago của ông vẫn chạy khi ông không còn. Các bài viết về permacomputer của ông tiếp tục lan truyền. Unhomeschool vận hành trên hạ tầng mà ông đã thiết kế.
Một đường ống MOAD trồng những hạt sồi. Mỗi lần hợp nhất upstream gieo một bản sửa lỗi vào mã nguồn chính thức. Trọng lực lan truyền nó. Các phiên bản tương lai của các dự án chưa từng nghe đến người vá lỗi gốc vẫn chạy mã sạch hơn nhờ công việc được thực hiện hôm nay.
Thiết kế Permacomputer không phải là lòng vị tha. Đó là kỹ thuật tốt. Một hệ thống đòi hỏi người tạo ra nó phải tồn tại là mỏng manh. Một hệ thống được thiết kế để tồn tại lâu hơn người tạo ra nó là mạnh mẽ. Lựa chọn thiết kế này không tốn thêm chi phí nào khi xây dựng; nó chỉ cần ý định.
Hạ tầng như một món quà: không theo nghĩa tình cảm, mà theo nghĩa kỹ thuật. Một món quà vẫn tồn tại sau khi trao tặng. Mã nguồn theo giấy phép cho phép, tài liệu được viết cho người bảo trì tiếp theo, các bài kiểm tra chạy trên CI công khai: đây là những món quà theo nghĩa kỹ thuật. Chúng tồn tại. Chúng phát triển. Chúng sống lâu hơn.
Câu hỏi cuối cùng của Hamming dành cho học trò: 'Bạn đang làm gì sẽ có ý nghĩa trong 20 năm nữa?' Câu trả lời của permacomputer: bất cứ thứ gì bạn đặt lên một nền tảng vững chắc.