- Động lực trực tiếp để rời GitHub không phải là sự cố tháng 4/2026, mà là vấn đề quyền sở hữu đối với mã nguồn và workflow chạy trên GitHub
- Từ sau tháng 8/2025, GitHub không còn CEO riêng mà được sáp nhập vào CoreAI division của Microsoft, và mã nguồn được đặt dưới tổ chức AI của Microsoft
- Từ tháng 4/2026, Copilot Free, Pro, Pro+ chuyển sang cơ chế opt-out, trong đó dữ liệu tương tác mặc định được dùng làm dữ liệu huấn luyện
- GitHub và Microsoft là công ty Mỹ nên chịu thẩm quyền của FISA 702 và CLOUD Act; chỉ riêng data residency tại EU là không đủ để giải quyết
- Forgejo v15 LTS đang chạy trên một NUC duy nhất của code.jorijn.com, còn runner được cô lập bằng KVM, gVisor, rebuild hằng tuần và bộ lọc egress
Lý do rời GitHub không phải là sự cố, mà là vấn đề quyền sở hữu
- Sự cố tháng 4/2026 đủ nghiêm trọng với các nhà phát triển, nhưng lý do cốt lõi để rời GitHub không phải là bản thân sự cố mà là quyền sở hữu đối với mã nguồn và workflow chạy trên GitHub
- Ngày 27/4/2026, Bộ Nội vụ Hà Lan soft-launch code.overheid.nl, một instance Forgejo tự lưu trữ dành cho mã nguồn của chính phủ
- Quản lý dự án Boris Van Hoytema cho biết nền tảng này xuất phát từ yêu cầu các bộ phải công bố mã nguồn tại một nơi mà họ “sở hữu” về mặt pháp lý
- Forgejo được ưu tiên hơn GitLab vì là mã nguồn mở hoàn toàn và mang lại mức tự do cần thiết cho chủ quyền số
- Git host mặc định cho mã nguồn cá nhân cũng đã chuyển sang code.jorijn.com, nơi Forgejo v15 LTS chạy trên cấu hình được gia cố của một NUC duy nhất
- Một số repository đã được chuyển, số còn lại vẫn đang chờ
- Khi hoàn tất migration, các repository công khai trên GitHub sẽ được archive và mỗi archive sẽ trỏ tới vị trí mới
Sự cố và tải AI
- Ngày 23/4/2026, đường dẫn mã squash-merge của merge queue đã âm thầm đảo ngược các commit vốn đã được merge trong 658 repository và 2.092 pull request sau một đợt rollout feature flag không hoàn chỉnh
- Các công ty gồm Modal và Zipline đã phải tự khôi phục dữ liệu thủ công
- Bốn ngày sau, Pull Requests, Issues và Packages tiếp tục ngừng hoạt động hơn 6 tiếng do một cụm Elasticsearch bị quá tải
- Chỉ riêng tháng 2/2026 đã ghi nhận 37 sự cố, trong đó có một lần gián đoạn 3 giờ 40 phút khiến Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot và Pages cùng ngừng hoạt động
- Ngày 1/10/2025 cũng xảy ra sự cố macOS runner kéo dài 10 giờ
- Theo thống kê của IncidentHub, từ tháng 5/2025 đến tháng 4/2026, GitHub ghi nhận 257 sự cố và 48 sự cố lớn, với tổng thời gian downtime khoảng 112 giờ
- Trong lời xin lỗi ngày 28/4 của CTO GitHub Vlad Fedorov, ông cho biết để theo kịp mức tải do “agentic AI workflow growth” từ sau tháng 12/2025, công suất sẽ phải tăng 30 lần
- Vấn đề độ tin cậy được hiểu như hệ quả thứ cấp của việc mở rộng các tính năng AI
- GitHub đang đẩy mạnh hơn nữa thay vì làm chậm các tính năng AI
- The Pragmatic Engineer chỉ ra rằng GitLab, Bitbucket, Vercel, Linear và Sentry đã không trải qua năm như vậy
- Các dịch vụ này cũng chịu áp lực từ nhu cầu của nhà phát triển, nên mô hình sự cố của GitHub có vẻ là vấn đề riêng của GitHub
Thay đổi tổ chức của GitHub
- Ngày 11/8/2025, Thomas Dohmke rời vị trí CEO GitHub, và Microsoft không bổ nhiệm CEO kế nhiệm
- GitHub được sáp nhập vào CoreAI division của Microsoft
- Doanh thu, kỹ thuật và hỗ trợ của GitHub báo cáo về Microsoft developer division dưới quyền Julia Liuson
- CPO của GitHub báo cáo cho VP AI platform của Microsoft
- Thương hiệu vẫn còn, nhưng lãnh đạo độc lập thì không còn
- Nhận định rằng từ 2018 đến 2024 Microsoft vẫn vận hành GitHub với một mức độ tách biệt nhất định là về thực chất đúng, nhưng sau tháng 8/2025 giả định đó khó còn giữ được
- Hiện nay, push code lên github.com đồng nghĩa với việc push code vào một đơn vị nằm dưới tổ chức AI của Microsoft
Thay đổi mặc định dữ liệu huấn luyện của Copilot
- Ngày 25/3/2026, GitHub công bố thay đổi chính sách quyền riêng tư có hiệu lực từ 24/4
- Dữ liệu tương tác của người dùng Copilot Free, Pro, Pro+, đặc biệt là prompt, output, đoạn mã và ngữ cảnh liên quan, sẽ được dùng để huấn luyện và cải thiện mô hình AI trừ khi người dùng từ chối
- Thay đổi cốt lõi là đây là cơ chế opt-out chứ không phải opt-in
- Người dùng Copilot Free, Pro, Pro+ sẽ đóng góp vào việc huấn luyện mô hình nếu không tắt trong trang cài đặt Copilot
- Không có chặn ở cấp repository
- Admin không thể chỉ định với GitHub rằng các tương tác trong một repository cụ thể không được dùng để huấn luyện
- Opt-out là thiết lập theo từng tài khoản người dùng, nên mỗi contributor phải tự chọn
- Kết quả là nếu người dùng Copilot Free/Pro/Pro+ làm việc với repository, codebase đó có thể trở thành nguyên liệu huấn luyện bất kể giấy phép là gì
- Ngoại lệ cho repository riêng tư cũng được áp dụng khá hẹp
- GitHub nói rằng họ không dùng nội dung “at rest” của repository riêng tư để huấn luyện
- Nhưng họ vẫn thu thập “code snippets and interaction context” được tạo ra trong khi dùng Copilot bên trong repository riêng tư
- Ranh giới giữa “mã ở trạng thái tĩnh” và “các đoạn được tạo ra trong lúc chỉnh sửa” là khá mơ hồ
- Khách hàng Copilot Business và Copilot Enterprise được loại trừ vì áp dụng Data Protection Agreements riêng
- Cấu trúc hiện tại là nếu trả đủ tiền thì tương tác không trở thành dữ liệu huấn luyện, còn nếu không thì sẽ trở thành dữ liệu huấn luyện
- Mối quan tâm chiến lược của GitHub với dữ liệu tương tác người dùng giờ đây không còn là yếu tố tùy chọn mà đã trở thành yếu tố mang tính cấu trúc
Rủi ro về thẩm quyền pháp lý không được giải quyết bằng vị trí dữ liệu
- GitHub Inc. và Microsoft Corp. là các công ty Mỹ, và dữ liệu họ nắm giữ thuộc phạm vi áp dụng của luật Mỹ, bao gồm FISA Section 702 và CLOUD Act 2018
- Hai đạo luật này có thể được áp dụng bất kể dữ liệu nằm ở đâu về mặt vật lý
- Section 702 đã được tái phê chuẩn thêm 2 năm vào ngày 4 tháng 4 năm 2024, và hiện vẫn có hiệu lực nhờ gia hạn 45 ngày được ký vào cuối tháng 4 năm 2026
- Cho phép cơ quan tình báo Mỹ thu thập dữ liệu nhắm tới người không phải công dân Mỹ thông qua các nhà cung cấp dịch vụ truyền thông điện tử đặt tại Mỹ
- CLOUD Act có thể buộc các công ty có trụ sở tại Mỹ phải giao nộp dữ liệu được lưu trữ ở bất kỳ đâu trên thế giới
- GitHub đã công bố EU data residency cho Enterprise Cloud đã chính thức khả dụng rộng rãi vào tháng 10 năm 2024
- Điều này giải quyết vấn đề vị trí dữ liệu, nhưng không giải quyết vấn đề thẩm quyền pháp lý
- Mức độ phơi nhiễm với CLOUD Act đi theo cấu trúc kiểm soát doanh nghiệp, chứ không theo vị trí địa lý
- Một luật sư phía Microsoft, dưới lời tuyên thệ tại phiên điều trần ở Thượng viện Pháp vào tháng 6 năm 2025, đã trả lời rằng không thể bảo đảm dữ liệu của Pháp lưu tại các trung tâm dữ liệu Microsoft ở châu Âu sẽ an toàn trước việc chính phủ Mỹ truy cập một cách âm thầm
- Chừng nào mã nguồn còn nằm trên github.com, chừng đó nó vẫn nằm trong phạm vi pháp lý của Mỹ
- EU data residency có thể mang lại cảm giác yên tâm, nhưng không phải là lời giải
Chính phủ Hà Lan chọn code.overheid.nl
- Nền tảng pháp lý đằng sau lựa chọn của chính phủ Hà Lan là chính sách “Open, tenzij” có hiệu lực từ năm 2020
- Phần mềm được phát triển bằng ngân sách công mặc định sẽ là mã nguồn mở, trừ khi có yêu cầu về bảo mật hoặc tính bí mật
- Để tuân thủ điều này, các bộ ngành cần một nơi công bố mã mà họ thực sự kiểm soát
- Ủy ban châu Âu đã vận hành code.europa.eu dựa trên GitLab tự lưu trữ từ tháng 9 năm 2022
- openCode của Đức cũng dựa trên GitLab
- code.gouv.fr của Pháp là một bộ tổng hợp lập chỉ mục các kho được lưu trữ ở nơi khác, chứ không phải một forge riêng
- Chính phủ Hà Lan đã chủ đích chọn Forgejo thay vì GitLab
- Theo OSOR, lý do là Forgejo hoàn toàn là mã nguồn mở, không có sự tách biệt open-core, và cung cấp mọi quyền tự do cần thiết cho quyền tự chủ số
- Van Hoytema cũng nói thêm rằng lộ trình của Forgejo “way more aligned” so với các lựa chọn thay thế
- Chính phủ Hà Lan không chỉ muốn một forge có chủ quyền, mà muốn một forge có chủ quyền không bị khóa sau các tầng premium của nhà cung cấp thương mại
- Chính phủ cũng nhìn thấy cùng một cấu trúc vấn đề và đi đến cùng một quyết định, khiến việc chọn Forgejo khó còn có thể bị xem là một lựa chọn bên lề
Vì sao chọn Forgejo
- GitLab cũng đã được cân nhắc nghiêm túc
- GitLab CE tự lưu trữ là một lựa chọn quen thuộc, có hệ sinh thái thương mại lớn hơn và UI được trau chuốt hơn
-
Giấy phép
- GitLab theo mô hình open core
- Community Edition dùng giấy phép MIT, nhưng nhiều tính năng mong muốn trong môi trường vận hành lại nằm ở tier Enterprise với giấy phép không tự do
- Forgejo thì đi theo hướng ngược lại
- Từ v9.0 vào tháng 8 năm 2024, dự án đã được đổi giấy phép từ MIT sang GPLv3+
- Mục tiêu được nêu rõ là duy trì copyleft và ngăn codebase bị thâu tóm mang tính thương mại trong tương lai
- Việc Forgejo fork từ Gitea vào tháng 12 năm 2022 cũng là vì Gitea Ltd kiểm soát thương hiệu và tên miền mà không có sự đồng thuận của cộng đồng
- Bài học đó đã được phản ánh trong lựa chọn giấy phép
-
Quản trị
- Forgejo thuộc Codeberg e.V.
- Codeberg e.V. là một tổ chức phi lợi nhuận đăng ký tại Berlin từ tháng 9 năm 2018
- Có hội đồng quản trị do thành viên bầu chọn, ngân sách công khai, và hơn 300.000 kho trên instance lưu trữ của mình
- Các thành viên bỏ phiếu cho ngân sách hằng năm
- Kế hoạch năm 2025 được thông qua với 88 phiếu thuận, 0 phiếu chống và 1 phiếu trắng
-
Phát hành và mức độ trưởng thành
- Forgejo v15.0 LTS được phát hành ngày 16 tháng 4 năm 2026
- Đây là bản phát hành thứ 100 của dự án
- Hỗ trợ dài hạn kéo dài đến ngày 15 tháng 7 năm 2027
- Forgejo Actions đã đạt mức cần thiết trong v15
- Bao gồm ephemeral runner, OpenID Connect và reusable workflow expansion
- Kể từ sau khi fork, các bản phát hành diễn ra đều đặn và các báo cáo hằng tháng cũng rất tích cực
-
Giới hạn của hệ sinh thái thương mại
- Hệ sinh thái thương mại của Forgejo có tồn tại nhưng còn mỏng
- Sản phẩm thương mại gọn gàng nhất hiện tại là Codey by VSHN
- Đây là Forgejo managed hosting tại Thụy Sĩ, ra mắt trên Servala vào tháng 3 năm 2025
- Giá khởi điểm từ 19 CHF mỗi tháng
- Không có gói thuê bao hỗ trợ doanh nghiệp kiểu Red Hat
- Nếu cần hỗ trợ điện thoại 24/7 và một nhà cung cấp đứng ra chịu trách nhiệm, bạn sẽ phải tự xây hoặc chờ thêm
Cấu hình code.jorijn.com
- code.jorijn.com chạy trên một Intel NUC duy nhất trong văn phòng tại nhà
- RAM là 64GB
- Forgejo v15 LTS, Postgres 17 và Traefik chạy trong Docker
- Máy ảo KVM do Incus quản lý chạy Forgejo Actions runner ở bên cạnh
- Quyết định quan trọng hơn cả việc bố trí Forgejo, Postgres hay reverse proxy là cấu hình runner
Runner là phần rủi ro nhất
- Với một forge tự lưu trữ, bản thân forge là phần dễ; phần khó là môi trường chạy các tác vụ CI
- Runner phải chạy
npm install, composer install, pip install mỗi ngày theo lịch của Renovate
- Mục tiêu là các lockfile được tạo ra từ chính kho mã của mình
- Điều này đồng nghĩa với việc thực thi lifecycle script
- Mọi tác vụ đều có thể chạy mã không đáng tin cậy ở mức tiềm tàng
- Rủi ro này tương tự như cách sâu npm gần đây và vụ tấn công chuỗi cung ứng axios đã di chuyển thông qua các bot phụ thuộc tự động merge chỉ trong vòng một giờ
- Vai trò của runner không phải là chạy mã, mà là cô lập mã đang chạy
- Thiết kế được xây dựng trên giả định rằng một lớp phòng thủ đơn lẻ có thể thất bại, và lớp tiếp theo phải hấp thụ được thất bại đó
Các lớp phòng vệ của runner
-
Máy ảo KVM tồn tại liên tục
- runner nằm trong một KVM VM riêng, không phải container trên host
- môi trường tác vụ không chia sẻ kernel của host
- để CVE của kernel Linux bên trong runner chạm tới NUC, trước hết phải phá vỡ ranh giới KVM
-
Dùng gVisor làm Docker runtime mặc định bên trong VM
- container tác vụ chạy dưới
runsc
runsc không chuyển syscall trực tiếp tới kernel host mà chặn chúng trong không gian người dùng- để thoát container phải phá được cả gVisor lẫn lớp KVM bao quanh
-
Rebuild phá hủy hằng tuần
- vào 02:00 UTC mỗi thứ Hai, toàn bộ VM bị xóa và được tạo lại từ Ubuntu base image mới
- persistent runner registration mới cho Forgejo cũng được cấp lại
- base image được rebuild vào Chủ nhật nên VM mới phản ánh các bản vá apt và kernel của tuần đó
- trạng thái lâu dài không thể tồn tại quá 7 ngày
-
Bộ lọc egress nftables của runner bridge
- runner có thể truy cập các đích công khai tại
:443, :80, :22, :53
- gồm npm, pypi, ghcr, và Forgejo tự host được truy cập qua hostname công khai bằng hairpin NAT
- không thể truy cập
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
- tác vụ bị xâm nhập không thể quét LAN hoặc truy cập giao diện quản trị router hay các dịch vụ khác trên host
-
Runner token giới hạn phạm vi
- hai persistent runner registration mỗi cái được gắn với đúng một phạm vi người dùng và một phạm vi tổ chức
- quản trị dùng PAT scope
write:user,write:organization
- token bị lộ không thể đăng ký runner ngoài phạm vi, cũng không thể làm tác vụ có admin scope
- các lớp được cố ý cấu hình để chồng lấp nhau
- mỗi lớp là một hàng rào, kết hợp lại tạo thành ranh giới phòng thủ theo chiều sâu
- KVM isolation, gVisor, rebuild hằng tuần và scope-bound runner registration đều là các thành phần được Forgejo và Incus hỗ trợ sẵn
Những gì đã đánh đổi
-
Khả năng được tìm thấy và đồ thị xã hội
- GitHub là nơi những người đóng góp tìm kho mã
- người muốn gửi một chỉnh sửa nhỏ tới kho công khai sẽ mong làm việc trên github.com hơn là một domain xa lạ
- khi việc di chuyển hoàn tất, kế hoạch là archive từng kho GitHub công khai và để README trỏ tới code.jorijn.com
- đường dẫn khám phá vẫn được giữ lại
- mọi người vẫn tìm thấy kho trên GitHub, thấy hướng dẫn archive rồi chuyển sang canonical home
- việc này vẫn chưa hoàn tất, mới chỉ có một số kho nằm trên code.jorijn.com, số còn lại vẫn đang chờ
-
Tính tương thích mong manh của hệ sinh thái GitHub Actions
- Forgejo Actions nhắm tới sự quen thuộc chứ không phải tương thích tuyệt đối
- phần lớn hoạt động, nhưng một số thì không
- khối
permissions: ở mức workflow bị bỏ qua một cách im lặng
actions/checkout@v6 đã làm hỏng authenticated checkout trên runner không phải GitHub vào đầu năm 2026, nên bị ghim ở v5actions/upload-artifact@v4 cần fork do Forgejo host- OIDC hoạt động, nhưng dùng workflow key khác là
enable-openid-connect: true thay vì permissions: id-token: write của GitHub
- nếu workflow phụ thuộc nhiều vào các tính năng riêng của GitHub, việc migrate sẽ không phải chuyện làm xong trong một buổi tối mà sẽ thành cả một dự án
-
Không có Dependabot
- Forgejo không có Dependabot
- Renovate được chạy 3 giờ một lần trên cùng runner tự host đó
- nó làm cùng vai trò, nhưng cần cấu hình nhiều hơn và mất một ngày để thiết lập
-
Không có hỗ trợ từ nhà cung cấp 24/7
- GitHub Enterprise cung cấp số điện thoại và SLA
- Forgejo cung cấp issue tracker và chat room
- như vậy là đủ cho vận hành một người, nhưng có thể không đủ cho một tổ chức 200 kỹ sư
Khi nào không đáng để chuyển
- nếu đội ngũ hoàn toàn không có ý chí hoặc năng lực vận hành hạ tầng, tốt hơn là đừng chuyển sang Forgejo tự host
- Codey, một dịch vụ Forgejo được quản lý, hoặc Codeberg cho FOSS có thể thu hẹp phần lớn khoảng cách, nhưng chi phí di chuyển vẫn còn đó
- nếu đã đầu tư sâu vào các tính năng riêng của GitHub như GitHub Apps marketplace, Codespaces, Copilot Workspace, Advanced Security thì đây không phải lựa chọn phù hợp
- Forgejo là một forge, không phải developer-platform-as-a-service
- nếu cơ sở cộng tác viên phụ thuộc vào đồ thị xã hội của GitHub, khả năng được tìm thấy có thể quan trọng hơn quyền sở hữu
- có thể ở lại nơi cộng tác viên đang có mặt, hoặc chấp nhận ma sát và sau khi chuyển xong thì archive các kho GitHub công khai để trỏ tới vị trí mới, rồi đánh giá lại sau
- nếu không có câu trả lời vận hành đáng tin cậy cho runner thì sẽ rất khó chuyển
- đây là phần cần được xử lý nghiêm túc nhất
- nếu chưa sẵn sàng suy nghĩ về KVM isolation, gVisor, nftables và rebuild hằng tuần, tốt hơn là chạy tác vụ CI trên managed runner host hoặc ở lại GitHub
- ngay cả chính phủ Hà Lan cũng không chuyển mọi thứ cùng lúc
- code.overheid.nl là một nền tảng soft launch để các bộ ngành chia sẻ mã nguồn mở, chứ không phải thay thế toàn diện mọi thứ họ dùng
- cấu hình của code.jorijn.com cũng theo cùng mô hình đó
- Forgejo là host chuẩn tắc, GitHub là mirror, và mirror có thể được đánh giá lại sau này
1 bình luận
Ý kiến trên Hacker News
Có vẻ như khi mọi người rời GitHub, họ đang quên mất tinh thần nguyên bản của git
git ban đầu được thiết kế theo hướng phi tập trung, và vấn đề là GitHub gọn gàng hơn, mở rộng tốt hơn và được quản lý tốt hơn, nên toàn bộ công cụ xung quanh git đã bị tập trung hóa về GitHub
Dù vậy, vẫn nên giữ lại các bản mirror tự động đồng bộ lên GitHub. Vì trong nhiều năm, tôi đã thấy các dự án chuyển sang tự host hoặc các dịch vụ host ngách, rồi mirror GitHub chết hoặc bị xóa, và cuối cùng dự án biến mất theo thời gian
git là phi tập trung và GitHub chỉ là một trong những nơi có thể đưa code lên, và bạn có thể push lên nhiều remote server
Vì thế tôi sẽ không commit code cá nhân của mình lên đó nữa
Tôi cũng không quan tâm tới các tính năng xã hội như khả năng được khám phá, star, hay các issue do bot AI xả ra. Trạng thái hiện tại là đủ với tôi
Và cũng nên nhớ rằng “Open Source is not about You”
Khía cạnh quan trọng nhất của nền tảng mà mọi người hay quên là thành phần xã hội, và việc nó giúp tạo ra các kho lưu trữ bên ngoài bền vững cũng như khiến hợp tác giữa các kho trở nên cực kỳ dễ dàng
Nó dùng các giao thức và tiêu chuẩn mở để kết nối các forge tự host với nhau
Rất ít người từng dùng nó theo mô hình patch qua email như dự định ban đầu, và phần lớn còn lại có lẽ cũng không muốn học
Về cơ bản, người ta dùng git vì GitHub dùng nó, hoặc nói rộng lượng hơn thì vì nó hoạt động tốt khi gắn với một host tập trung kiểu GitHub
Họ bị thu hút bởi mô hình phát triển code cục bộ và thảo luận issue cùng patch trên cổng web, còn phần do chính git cung cấp thì khá nhỏ
Issue, release, CI, tài liệu, khuyến cáo bảo mật, tìm kiếm và khả năng được khám phá đều có xu hướng bị khóa vào GitHub theo thời gian
Với dự án mã nguồn mở, tôi nghĩ cách tốt là lấy tự host làm nguồn chân lý, nhưng vẫn duy trì mirror GitHub chỉ đọc để mọi người thực sự tìm thấy nó
Thứ thật sự có thể thay đổi cuộc chơi là hỗ trợ federation hoàn chỉnh
Vì vậy tôi đang quyên góp cho Forgejo và Codeberg, và khuyến khích mọi người đóng góp thêm thời gian và nguồn lực để đội Forgejo triển khai được cho ra hồn
Một ứng viên tốt khác là Radicle, hoàn toàn phi tập trung trên nền Git
https://codeberg.org/forgejo-contrib/federation/src/branch/m...
https://liberapay.com/forgejo
https://donate.codeberg.org/
https://radicle.dev/
https://radicle.network/nodes/seed.radicle.dev
Tôi cũng đã chuyển git repository của mình sang NUC tự host
Tôi vẫn chưa gắn frontend HTTP để chia sẻ với thế giới, vì tôi không muốn cung cấp nội dung cho AI scraper và cũng không muốn phải tốn công chặn chúng
Thật đáng xấu hổ khi các công ty từng hưởng lợi từ mã nguồn mở lại làm ô nhiễm ngành theo cách này
Nó đã chạy được 3 năm. Nếu khóa lại chỉ cho truy cập trong LAN và không public lên Internet thì cảm giác sử dụng rất bền và ổn định
Repository mirror ổn trong vài tuần rồi dừng. Tôi đã nhập PAT token không hết hạn, nhưng nó vẫn bảo là token đã hết hạn, trong khi test ở nơi khác thì token hoạt động bình thường
Có lúc log chẳng có gì, lúc khác thì database bị khóa. Forgejo là thứ duy nhất dùng database đó
Đến giờ tôi vẫn chưa phân biệt được đây là vấn đề của Forgejo, do SD card I/O tệ hại trên Pi gây khóa database, hay đơn giản là Forgejo không hợp làm mirror
Các công ty cloud độc quyền siêu lớn nhận được lao động miễn phí, rồi dùng nó để tạo ra thế giới mà chúng ta ghét: mạng lưới giám sát theo dõi, điện thoại không thể cài tùy ý, chứng thực thiết bị, văn hóa trình duyệt đơn nhất không có chặn quảng cáo
Google đã khiến mọi người yêu BSD/MIT, và cứ nhìn kết quả là rõ
Một chiêu điển hình là “giờ thì nó là của chúng tôi”. Khi vendor tạo ra thứ như Elasticsearch hay Redis, các hyperscaler sẽ biến nó thành sản phẩm độc quyền của mình và lấy hết lợi nhuận, còn tác giả gốc và công ty thì chết đói
Một chiêu khác là “ôm lấy, mở rộng, tiêu diệt”. Họ lấy các dự án mã nguồn mở như KHTML hay Linux, tạo ra phiên bản của riêng mình, tung ra thị trường để đè đối thủ, rồi bằng các biện pháp phản cạnh tranh đặt sản phẩm của họ ngay trước mắt mọi người, và khi đã có thị phần thì nhét theo dõi vào và loại bỏ tự do
Mã nguồn mở nên được thay bằng mô hình “con người thì tự do, doanh nghiệp thì phải trả tiền”. Ta cần kiểu shareware công khai mã nguồn có răng để đối đầu hyperscaler
Ngay cả giấy phép của Richard Stallman cũng chưa đủ mạnh, tôi thấy CC BY-NC-SA còn tốt hơn
Mã nguồn mở “thuần khiết” là phúc lợi doanh nghiệp và là một sai lầm. Chúng ta đã đưa cho những gã khổng lồ sợi dây để chúng treo cổ chính mình
Tôi rất muốn AI tích cực đọc code của mình
Ở mục “What I gave up”, tác giả nhắc đến đồ thị xã hội của mình, nhưng dùng GitSocial thì bạn có thể mang theo đồ thị xã hội và lịch sử cộng tác
Nó cho phép pull request liên forge giữa bất kỳ git host nào, và hoạt động hoàn toàn không phụ thuộc bên thứ ba
Đó là lý do những lựa chọn thay thế này rất khó cất cánh
Đọc đoạn “CTO đã công khai xin lỗi và nói rằng để gánh tải do AI tạo ra thì họ phải tăng công suất lên 30 lần”, tôi hy vọng GitHub sẽ không bắt đầu tính phí cho việc dùng thông thường
Nhưng nhìn vài vibe coder tạo ra hàng nghìn commit mỗi ngày thì tôi ngày càng bi quan hơn
Sẽ thật đáng tiếc nếu chúng ta không còn thể chia sẻ và cộng tác code miễn phí nữa
Người có kinh nghiệm chỉ mất vài giây để nhận ra khi repository gặp kiểu vấn đề này, nên một hệ thống được tinh chỉnh cũng có thể làm được
Phần khó là viết điều khoản pháp lý để có thể áp hạn ngạch vibe
Anthropic đã làm vậy trong mảng CC, và GitHub với GitLab chắc cũng sẽ làm điều tương tự. Đổi lại chỉ là bị các dev Twitter và một phần subreddit nhỏ ghét thôi, nhưng có vẻ hoàn toàn đáng để chịu
Mặt khác, tôi khá ngạc nhiên khi thường xuyên thấy ở /r/vibecoding có người trả 200 USD mỗi tháng tiền thuê bao để làm các dự án hobby hoặc những website gần như chỉ là đồ chơi
Tôi cũng từng tiêu tiền ngu khi còn kham nổi, nhưng chuyện này cho cảm giác hơi khác
Có khi đó là đang trả 2400 USD một năm cho một dịch vụ mang lại ý nghĩa và mục đích. Nếu tới tầm 40 tuổi và nhận ra mình sẽ không thể giàu hay nổi tiếng, thì so với những lựa chọn khác, cái giá đó có thể vẫn chấp nhận được
Tôi cũng nghe về Tangled, một dịch vụ phi tập trung xây trên AT Protocol giống Bluesky
Nó còn có những tính năng thực sự hữu ích như stacked pull request, thứ mà GitHub từng chần chừ mãi không triển khai đến mức có cả công ty mọc lên để thêm tính năng đó vào GitHub
Không biết có ai đã dùng thử chưa
https://tangled.org/
https://tangled.org/h14h.com/knot
Nhìn chung nền tảng này khá hứa hẹn. Cách AtProto tách personal data server, relay và AppView có vẻ là một thỏa hiệp hợp lý
Bạn có thể host git repository như một máy chủ dữ liệu không đầu chỉ chuyên về dữ liệu, nên với tự host thì gần như không đau đớn mấy
So với giải pháp ActivityPub kiểu Forgejo, tôi chỉ quan tâm đến quyền kiểm soát dữ liệu, nên thật tốt khi tránh được sự nhàm chán của việc phải host và scale cả một webapp hoàn chỉnh
Từ sau thiết lập ban đầu, việc vận hành bảo trì chỉ là nâng phiên bản knot-server rồi deploy lại. Nếu tangled.org đang dùng bản cũ thì nó sẽ hiện banner cảnh báo
Tôi muốn dùng Tangled nhiều hơn ở các dự án khác và thử thêm các tính năng. Đặc biệt tôi quan tâm đến hỗ trợ native cho jj và stacked PR
Cũng có những thử nghiệm thú vị như tack để nối CI tùy biến
Khi ATProto hỗ trợ dữ liệu riêng tư, có lẽ một ngày nào đó nó cũng sẽ hỗ trợ repository riêng tư, nhưng chắc sẽ mất thời gian
https://tangled.org/mitchellh.com/tack
Vẫn chưa thấy nhắc gì đến mô hình kinh doanh, nên tôi thật sự tò mò nó sẽ thành cái gì
Tôi thích dùng radicle.xyz hơn
Fossil cũng đáng cân nhắc
Nó gói toàn bộ trạng thái repository, gồm lịch sử code, wiki, ticket và diễn đàn, vào một file duy nhất, rồi trạng thái đó được nhân bản
Khi phải đổi nhà cung cấp hosting, với Fossil sẽ không có dữ liệu nào bị mất vì chuyện đó
https://fossil-scm.org/
Nhưng hiệu ứng mạng là vấn đề. Tôi không thể kéo cả team sang Fossil được
Team cần chia sẻ code với người khác, với các bộ phận khác, và mọi người, thực tế là hơn 99%, đều dùng git
Ép team dùng Fossil còn có cảm giác gây hại hơn, nên đúng là tiến thoái lưỡng nan
Nó giống nhiều chuyện khác trong kỹ thuật. Ví dụ như cố bắt đồng nghiệp dùng thành ngữ phong cách hàm hay áp đặt tính bất biến
Có cảm giác phải cần một dự án lớn kiểu Facebook hay Google ép cả cộng đồng dịch chuyển
Nhưng về mặt triết lý thì tôi không thích Fossil. Nó không có cách dọn dẹp lịch sử, mà giữ nguyên tất cả mọi thứ
Nếu đó là điều bạn muốn thì rất ổn, nhưng với workflow git của tôi, tôi thích thử nghiệm linh tinh rồi dọn và sắp xếp lại commit trước khi push
Mọi người lúc nào cũng hô hào phi tập trung hóa
Nhưng trên thực tế, phần lớn hệ thống cuối cùng vẫn bị tập trung hóa
Có lẽ khi người ta đòi phi tập trung hóa, thứ họ thật sự tìm kiếm là một trung tâm mới nơi chính họ có thể trở thành người khai phá đầu tiên
Nếu họ cảm thấy không có cơ hội thắng theo luật chơi hiện tại, thì có vẻ họ lấy danh nghĩa phi tập trung hóa để lật bàn
Lý do mọi người muốn như vậy là vì kiểu quản trị tập trung đơn nhất đó, vì lý do này hay lý do khác, là chưa đủ tốt
Không có khác biệt nào giữa chuyện mọi người hô hào và chuyện họ thực sự muốn nó
Tệ hơn nữa là hệ thống tập trung thì hoạt động rất tốt trong phần lớn thời gian, còn nỗi đau chỉ ập đến dữ dội trong thời gian ngắn như khi sáp nhập hay tăng giá đột ngột
Phi tập trung thì lúc nào cũng đau âm ỉ một chút, đổi lại là niềm hạnh phúc lớn trong những thời điểm hiếm hoi khi lựa chọn tập trung sụp đổ
Thông thường thì cách nói đó là tẩy chay. Người ta không nói “bánh kẹo bị tập trung hóa quá mức vào Nestlé nên ta cần phi tập trung hóa bánh kẹo”
Tôi đang chuyển sang Tangled, được xây trên AT Protocol nên dùng cùng tài khoản với Bluesky và các dịch vụ khác
Dùng thử thấy khá thích
https://vale.rocks/micros/20260511-0440
Từ một năm trước tôi đã chuyển sang Gitea tự host trong homelab và chặn truy cập công khai
Không có HTTPS, đã tắt đăng ký, và repository cũng không public
Tôi đang cân nhắc dựng một instance công khai và dùng HTTPS nhưng vẫn giảm thiểu bề mặt tấn công, nhất là muốn nghe gợi ý liên quan tới Gitea/Forgejo
Điều quan trọng là tắt đăng ký cục bộ. Với tôi thì dùng authentik làm IdP, chỉ truy cập được từ tailnet. Hoặc bạn có thể tự tạo tài khoản xong rồi tắt đăng ký
Tôi cũng chặn một số phần bằng robots.txt như trang xem commit git được render riêng lẻ. Nếu không thì scraper sẽ rơi vào vòng lặp vô tận
Tôi cũng cấm rất chặt việc truy cập kho package của Forgejo, vì tôi có package riêng tư và mức độ phân quyền ở đó vẫn chưa đúng như tôi muốn nên còn đang tinh chỉnh
Tôi vẫn đang theo dõi và tới giờ chưa có vấn đề lớn nào. Có chi tiết hơn ở docs.eblu.me, nếu muốn tôi còn có thể gửi thẳng mã hạ tầng
Trước đây tôi dựng một instance public chỉ đọc để mirror instance nội bộ, rồi thiết lập một kết nối reverse proxy duy nhất từ trong ra instance public để bên public lấy dữ liệu git
Sau đó nhìn chung nó tự chạy ổn, và mỗi khi thay đổi gì ở Forgejo nội bộ thì bên public cũng được cập nhật
Issue, CI, v.v. đều có thể giữ hoàn toàn riêng tư trong LAN
Tôi tò mò vì sao bạn vẫn dùng Gitea. Giờ tôi lại đang cân nhắc có nên thử Gitea thay vì Forgejo nữa không