Dự án Dillo chuyển khỏi GitHub

 (dillo-browser.org)
2 điểm bởi GN⁺ 2025-12-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Dự án trình duyệt web Dillo đang trong quá trình chuyển từ GitHub sang máy chủ tự lưu trữ
  • Các lý do chính cho việc chuyển đi gồm phụ thuộc vào JavaScript của GitHub, cấu trúc kiểm soát tập trung và hiệu năng chậm
  • Máy chủ mới được vận hành trên tên miền dillo-browser.org và sử dụng giao diện Git nhẹ dựa trên cgit cùng trình theo dõi lỗi tự phát triển ‘buggy’
  • Toàn bộ dữ liệu được quản lý bằng kho git và mirror sang Codeberg cùng Sourcehut, giúp giảm thiểu rủi ro mất dữ liệu
  • Hệ thống được thiết kế để duy trì độ tin cậy ngay cả khi mất DNS thông qua chữ ký OpenPGP, qua đó củng cố tính độc lập và khả năng duy trì lâu dài của dự án

Bối cảnh

  • Trước đây, trang gốc của Dillo là dillo.org, bao gồm kho Mercurial, máy chủ thư, trình theo dõi lỗi và kho lưu trữ danh sách thư
    • Năm 2022, dự án đã mất tên miền này và một bên thứ ba đã dựng một trang tương tự đầy quảng cáo AI
    • Một phần dữ liệu đã được khôi phục, nhưng không đầy đủ
  • Từ trải nghiệm đó, dự án quyết định tránh phụ thuộc vào một trang duy nhất và xây dựng cấu trúc sao lưu phân tán
  • Ban đầu mã nguồn được đưa lên GitHub, nhưng về lâu dài dự án đánh giá đây không phải lựa chọn phù hợp

Các vấn đề của GitHub

  • GitHub hữu ích cho quy trình CI và quản lý kho, nhưng có nhiều giới hạn
    • Giao diện không hoạt động nếu không có JavaScript, nên không thể xem issue hay PR bằng trình duyệt Dillo
    • Các trang tiêu thụ tài nguyên quá mức, tạo gánh nặng không cần thiết cho việc hiển thị HTML đơn giản
  • Có rủi ro tài khoản bị chặn bởi một chủ thể kiểm soát duy nhất, khiến việc truy cập dữ liệu có thể bị cắt đứt
  • Nền tảng ngày càng chậm hơn và đòi hỏi kết nối Internet nhanh
  • Cách thông báo theo mô hình “push” của GitHub không phù hợp với phương thức phát triển ưu tiên làm việc ngoại tuyến
  • Việc thiếu công cụ quản lý cộng đồng cho các dự án có tỷ lệ người dùng không phải lập trình viên cao làm gia tăng sự mệt mỏi cho nhà phát triển
  • Khi GitHub chuyển trọng tâm sang LLM và AI tạo sinh, các trang web cũng tăng cường rào chắn JavaScript hoặc lấy dấu vân tay trình duyệt để chặn crawler LLM
    • Điều này gây ra tác dụng phụ là người dùng Dillo bị chặn truy cập

Xây dựng hạ tầng tự lưu trữ

  • Các dịch vụ forge hiện có không thể đồng thời đáp ứng việc loại bỏ điểm lỗi đơn lẻ và vận hành nhẹ
    • Vì vậy, dự án quyết định tự vận hành máy chủ và duy trì nhiều mirror
  • Dự án đã mua tên miền dillo-browser.org và thiết lập một máy chủ VPS nhỏ
    • Hệ thống đang vận hành ổn định hơn dự kiến và chủ yếu xử lý lưu lượng từ bot AI
  • cgit được chọn làm giao diện Git
    • Được viết bằng C nên dùng ít RAM và CPU, đồng thời hoạt động không cần JavaScript
    • Một phần CSS đã được chỉnh sửa để hiển thị tốt trong Dillo
    • Có thể truy cập tại https://git.dillo-browser.org/
  • Trình theo dõi lỗi sử dụng ‘buggy’, công cụ do dự án tự phát triển
    • Phân tích các tệp Markdown để tạo trang HTML, mỗi lỗi được lưu trong kho git
    • Git hook sẽ tự động cập nhật trang khi có commit
    • Có thể chỉnh sửa ngoại tuyến và không có lo ngại về lỗ hổng bảo mật
    • Có thể xem tại https://bug.dillo-browser.org/
  • Kho lưu trữ danh sách thư được phân tán trên 3 dịch vụ bên ngoài, và dự kiến sẽ bổ sung thêm bản sao tự lưu trữ trong tương lai

Cấu hình mirror

  • Tất cả dữ liệu cốt lõi được quản lý dưới dạng kho git và được mirror sang Codeberg và Sourcehut
    • Ngay cả khi một dịch vụ lưu trữ cụ thể ngừng hoạt động, dự án vẫn có thể chuyển sang mirror khác với chi phí thấp
  • Điểm lỗi đơn lẻ còn lại là DNS (dillo-browser.org)
    • Nếu mất DNS, dự án vẫn có thể thông báo cho người dùng qua danh sách thư, Fediverse, IRC và các kênh khác
    • Dữ liệu đã được sao chép trong git nên sẽ không xảy ra mất mát nghiêm trọng

Chữ ký OpenPGP

  • Trang này được ký bằng khóa GPG của Rodrigo Arias Mallo (32E65EC501A1B6FDF8190D293EE6BA977EB2A253)
    • Đây là cùng khóa dùng cho bản phát hành mới nhất của Dillo và cũng đã được đăng ký với tài khoản GitHub
    • Tệp chữ ký (index.html.asc) được liên kết bằng <link rel=signature>
  • Chữ ký OpenPGP cho phép duy trì độ tin cậy ngay cả khi mất DNS
    • Thay vì chuỗi chứng chỉ TLS, quyền sở hữu được chứng minh dựa trên mức độ tin cậy của chữ ký
    • Chữ ký cũng được đưa vào tất cả mirror git để tăng khả năng chống chịu trước mất mát dữ liệu

Tiến độ di chuyển và triển vọng

  • Kho GitHub sẽ không bị xóa ngay lập tức và sẽ tiếp tục được cập nhật cho đến khi hoàn tất quá trình chuyển đổi
    • Sau khi hoàn tất, kho sẽ được chuyển sang trạng thái ‘archived’ và thông báo trên trang chính thức
    • Các commit hiện có và tệp phát hành sẽ được giữ lại để tương thích với các bản dựng cũ
  • Hạ tầng mới có thể vận hành độc lập với chi phí và mức tiêu thụ năng lượng thấp
    • Theo mức quyên góp hiện tại và chi phí máy chủ, hệ thống có thể duy trì ít nhất 3 năm
    • Nếu muốn hỗ trợ, có thể ủng hộ qua Liberapay (https://liberapay.com/dillo/)

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-12-01
Ý kiến Hacker News

  • Đã dùng GitLab làm phương án thay thế tự host trong vài năm. Tôi thích nó, nhưng ngốn tài nguyên rất nhiều
    Gần đây tôi đang thử Forgejo do đội ngũ Codeberg tạo ra, và nó thực sự rất tuyệt
    Khác biệt lớn nhất là mức dùng bộ nhớ. GitLab dựa trên Ruby on Rails nên nhiều dịch vụ chạy đồng thời, còn Forgejo là kiến trúc một binary duy nhất viết bằng Go
    GitLab dần dùng hết bộ nhớ của VM 16GB, trong khi Forgejo chỉ dùng khoảng 300MB ngay cả khi chạy cả server lẫn runner
    Không có GraphQL, nhưng REST API có vẻ đủ tốt
    Tôi không rõ khác biệt giữa gitea và forgejo, nhưng xem tài liệu so sánh của Forgejo thì có vẻ nó là một soft fork tách ra vào năm 2022 vì vấn đề quản trị

    • Studio của chúng tôi có khoảng 50 người dùng dùng git mỗi ngày, và đã chuyển hẳn sang Forgejo cách đây 2 năm
      Cấu trúc đơn giản dựa trên Go nên bảo trì rất nhẹ và chi phí rất thấp. Chúng tôi cũng xây công cụ nội bộ trực tiếp trên Forgejo
      Vì host on-premise nên dù mất Internet thì việc phát triển và CI vẫn không dừng lại. Nó cũng hỗ trợ cache package manager nên quản lý dependency rất dễ
    • Về độ tiện khi bảo trì thì gitea vượt trội hẳn. Tôi đã dùng hơn 5 năm, và nâng cấp chỉ là pull bản mới rồi khởi động lại daemon là xong
      Nó có downtime ít hơn GitHub 10 lần, mà phần lớn còn là bảo trì theo kế hoạch
      Mỗi khi thấy bài viết cho rằng GitHub có độ sẵn sàng tốt hơn là tôi lại bật cười
    • Nếu là dự án cá nhân thì tôi nghĩ chỉ cần SSH server và filesystem là đủ
      Khi tạo repo mới chỉ cần git init --bare, còn backup cũng chạy tự động
      Nếu phát triển một mình thì tôi thấy UI không thực sự cần thiết
    • Xem tài liệu khái niệm cơ bản của Forgejo Actions thì hệ thống CI được tổ chức khá tốt
      Tôi nghĩ CI kiểu GitLab tốt hơn nhiều so với GitHub Actions, GitHub trở thành tiêu chuẩn nhờ độ phổ biến nhưng thiết kế thì khá đáng tiếc
    • Nếu muốn một lựa chọn tối giản hơn nữa thì có cả Gerrit. Đây là ứng dụng Java không phụ thuộc DB bên ngoài, và lưu cấu hình cùng thông tin runtime trong repo git
      Chỉ với filesystem dùng chung cũng có thể mở rộng và backup rất đơn giản

  • Tôi điều hành một câu lạc bộ toán ở địa phương, và bọn trẻ dùng Forgejo để nộp bài tập LaTeX và Python
    Việc quản lý đăng nhập và đặt lại mật khẩu rất dễ, nên nó cũng cực kỳ hữu ích cho mục đích giáo dục

  • Tôi đồng cảm với ý kiến không thích mô hình thông báo đẩy của GitHub và chỉ muốn xem cập nhật khi tự mình kiểm tra
    Nếu dùng lọc email thì có thể biến thông báo đẩy thành mô hình kéo. Chỉ cần gom thông báo vào một thư mục riêng và xem khi cần

    • Nếu vậy mà vẫn chưa hài lòng thì có thể dùng ngay chức năng thông báo trong giao diện GitHub. Thật ra cảm giác như đang cố tìm vấn đề để phàn nàn vậy

  • Câu chuyện của người tự làm bug tracker đơn giản tên là 'buggy' khá thú vị. Đó là một công cụ C phân tích Markdown để tạo trang HTML
    Tinh thần hacker vẫn còn sống

    • Nhưng tôi nghĩ gần như sẽ chẳng có ai đi theo cách đó. Nếu là tôi thì có khi còn tự làm tăng thêm rắc rối
    • Đây là một cách tiếp cận có cả ưu lẫn nhược điểm

  • Có người hỏi sự khác nhau giữa “push model” và “pull model” là gì

    • Có lẽ đang nói tới workflow dựa trên email như Source Hut hay Linux kernel. Có thể lấy patch về cục bộ qua IMAP và làm việc cả khi offline
    • Push tạo áp lực thời gian kiểu “làm ngay bây giờ”, còn pull là khác biệt trong cách quản lý thời gian: tôi kiểm tra theo chu kỳ do mình quyết định

  • Tôi nghĩ hiện tại đang là giai đoạn phân tán kiểu diaspora khi hàng loạt lựa chọn thay thế GitHub xuất hiện
    Có thể trong vài tháng tới sẽ có một cái tên chủ đạo nổi lên. Nếu một công ty hay cá nhân nổi tiếng tung ra nền tảng mới thì họ cũng có thể dẫn dắt thị trường

    • Xu hướng này đã có từ 10 năm trước rồi. Hồi đó là thời kỳ chuyển sang GitLab, và ngay cả bây giờ khả năng khám phá (discoverability) của GitHub vẫn là vô đối
      Số dự án rời GitHub vẫn cực ít nên tôi nghĩ còn quá sớm để kết luận
    • Mỗi lập trình viên có cách cộng tác khác nhau, nên khó mà hội tụ vào một giải pháp duy nhất
      Ngược lại, đang có tái phân tán (re-decentralization). Đây là thời đại mỗi người chọn forge phù hợp với quyền kiểm soát, thẩm quyền pháp lý và workflow của mình
    • Trong tương lai, mục tiêu là đi theo cấu trúc liên hợp (federation) thay vì tập trung như GitHub. Khi đó sẽ không còn phụ thuộc vào một thực thể duy nhất
    • Điều quan trọng là: bạn muốn một “phương án thay thế duy nhất”, hay muốn 5 năm nữa lại lặp lại tình huống hiện tại?
    • Chúng tôi đang thử làm đúng điều đó. Chúng tôi đang chuẩn bị một nền tảng cộng tác tập trung vào indie tên là Tangled, và sắp có một thông báo lớn

  • Tôi muốn mời dự án Dillo sang Tangled → tangled.org

    • Khá ấn tượng vì nó hoạt động tốt ngay cả khi không có JavaScript
    • Tôi muốn nó hỗ trợ cả các hệ thống quản lý phiên bản ngoài Git

  • Tôi nghĩ vấn đề lớn nhất là trải nghiệm sử dụng ngày càng chậm của GitHub

    • Tôi tò mò không biết cách nói “more and more slow” có tự nhiên không. “slower and slower” có phổ biến hơn không?
    • Trước đây còn ổn, nhưng gần đây tải trang chậm quá mức. Có vẻ không chỉ vì React
      Việc duyệt code thì tôi giải quyết bằng github.dev, nhưng PR và Actions thì vẫn chậm và bực bội

  • Nếu muốn cài Forgejo trên VM, tôi đã làm một script có thể thiết lập cả server lẫn runner cùng lúc → easyforgejo

  • Tôi không có chuyên môn sâu về chủ đề này, nhưng đọc rất thấy thú vị
    Thật ngạc nhiên khi chỉ riêng việc thiết lập một hệ thống quản lý phiên bản mà lại có nhiều yếu tố như vậy
    Tôi dùng Fossil, và với tổ chức nhỏ nơi một người kiêm luôn vai trò lập trình viên, quản trị hệ thống và hỗ trợ, nó đơn giản hơn nhiều
    Giới hạn deploy key của GitHub cũng bất tiện. Khi vận hành nhiều ứng dụng và server, phải cấu hình khóa riêng cho từng cái nên rất phiền