- terminal emulator bổ sung những yếu tố mới cho phạm vi phần mềm tốc độ cao và đã trưởng thành đang được chuyển khỏi GitHub sang một kho mã cộng tác khác
- Mitchell Hashimoto đã đăng ký GitHub vào tháng 2/2008 với tư cách người dùng số 1299 và đã sử dụng gần như mỗi ngày kể từ đó, từng xem GitHub là nơi khiến anh hạnh phúc nhất
- Trong một tháng gần đây, gần như ngày nào cũng có ghi nhận việc độ tin cậy của dịch vụ suy giảm ảnh hưởng đến công việc, và ngay trong ngày viết bài anh cũng không thể review PR trong khoảng 2 giờ do sự cố GitHub Actions
- GitHub không còn là nơi thú vị nữa, và sau 18 năm sử dụng anh quyết định rời đi, nhưng vẫn để ngỏ khả năng quay lại nếu có kết quả thực tế và cải thiện thực sự
- Việc chuyển Ghostty đang được tiến hành từng bước sau khi thảo luận với nhiều nhà cung cấp commercial và FOSS, theo hướng giữ lại một bản mirror chỉ đọc trên GitHub
Bối cảnh sử dụng Ghostty và GitHub
- Dự án chủ lực hiện tại là Ghostty, một terminal emulator bổ sung những “interesting new wrinkles” vào hạng mục phần mềm tốc độ cao và đã trưởng thành
- Việc phát triển Ghostty vẫn dùng GitHub, và Mitchell Hashimoto đã đăng ký GitHub vào tháng 2/2008 với tư cách người dùng số 1299 rồi sử dụng gần như mỗi ngày kể từ đó
- GitHub từng là “nơi khiến anh hạnh phúc nhất”, một dịch vụ anh gắn bó lâu đến mức ngay cả trong tuần trăng mật cũng dành thời gian cho nó
- Thay vì doom scrolling trên mạng xã hội, từ lâu anh đã xem GitHub issues, và cả trong kỳ nghỉ cũng nghiên cứu mã nguồn, quy trình OSS và cách maintainer phản hồi trong các dự án GitHub
Sự cố cản trở công việc mỗi ngày
- Gần đây cảm xúc của anh với GitHub đã thay đổi mạnh, đến mức GitHub khiến anh thất bại mỗi ngày và vấn đề đó được cảm nhận rất cá nhân
- Nguyên nhân cốt lõi là độ tin cậy của dịch vụ suy giảm; trong tháng vừa qua, mỗi ngày sự cố GitHub ảnh hưởng tiêu cực đến khả năng làm việc đều được đánh dấu “X” trong nhật ký
- Nhật ký đó gần như ngày nào cũng có “X”, và ngay trong ngày viết bài anh cũng không thể review PR trong khoảng 2 giờ vì GitHub Actions outage
- Bài viết này được viết vài ngày trước incident ngày 28/4, khi pull request không thể hoàn tất vì sự cố Elasticsearch
- Nếu những sự cố như vậy chặn công việc vài giờ mỗi ngày, thì GitHub không còn là nơi dành cho “serious work” nữa
Luồng phát triển và sự tách rời về cảm xúc
- GitHub không còn là nơi thú vị nữa; đúng như câu “I want to ship software and it doesn't want me to ship software”, nó đã trở thành thứ ngăn cản việc phát hành phần mềm
- Anh hy vọng GitHub sẽ cải thiện, nhưng đồng thời anh vẫn phải viết code, và hiện tại với GitHub thì anh không thể tiếp tục lập trình được nữa
- Sau 18 năm sử dụng, anh đi đến kết luận rằng mình phải rời đi, nhưng vẫn để ngỏ khả năng quay lại nếu có kết quả thực tế và cải thiện thực sự
- Điều kiện để quay lại GitHub không phải là lời nói hay lời hứa, mà là kết quả và cải thiện có thật
Cách Ghostty di chuyển
- Ghostty đang trong quá trình chuyển sang một collaborative code locker khác
- Anh đang thảo luận với nhiều provider, bao gồm cả provider thương mại và provider FOSS
- Việc loại bỏ toàn bộ sự phụ thuộc vào GitHub sẽ mất thời gian, và kế hoạch là thực hiện từng bước nhiều nhất có thể
- Trên GitHub sẽ vẫn giữ một mirror chỉ đọc của Ghostty, và các dự án cá nhân của anh cũng sẽ tiếp tục được đặt trên dịch vụ thuộc sở hữu của Microsoft
- Ghostty là dự án chịu ảnh hưởng lớn nhất đối với bản thân anh, các maintainer và cộng đồng mã nguồn mở, nên trở thành trọng tâm của thay đổi lần này
Vị thế của GitHub và bối cảnh Microsoft
- Sau khi Microsoft mua lại GitHub, đã có lo ngại rằng nó sẽ trở thành một dịch vụ thiên về Redmond và kém thân thiện hơn với các nhà phát triển không gắn với hệ sinh thái Windows hay Azure
- Lo ngại đó phần lớn đã không thành hiện thực, và GitHub đã trở thành de facto place để làm việc và chia sẻ mã nguồn
- Trải nghiệm của Hashimoto cho thấy vị thế đó có thể bị lung lay, đồng thời trùng với thời điểm Microsoft thừa nhận Windows has serious quality problems
- Một phần nguyên nhân của vấn đề chất lượng Windows được cho là do ép nhồi AI vào quá nhiều công cụ, và sự gia tăng bất ổn của GitHub mà Hashimoto chứng kiến cũng xuất hiện trong cùng giai đoạn Microsoft bị ám ảnh với AI
1 bình luận
Ý kiến trên Hacker News
Tôi cực kỳ bực vì đúng lúc công ty chuyển mọi thứ từ CircleCI sang GitHub Actions thì độ ổn định của GitHub lại sụp đổ
Điều khó tin nhất là ngay cả Azure Repos/Pipelines còn tốt hơn thế này
Tôi cũng có nghe nói GitHub vẫn đang trong quá trình chuyển sang hạ tầng Azure nên có thể đang ở trạng thái nửa vời, nhưng điều đó không khiến tôi tin tưởng hơn
Có thể chỉ là cái cớ, nhưng nghe cũng khá hợp lý
Tôi cũng muốn dùng thứ như Forgejo, nhưng đội chỉ khoảng 12 lập trình viên và nói thật là mới chỉ mình tôi từng dùng nó
Nó thật sự rất cơ bản nên chẳng có nhiều thứ để hỏng, và vì lý do tương tự tôi cũng rất thích hệ thống ticket của nó
Nó chỉ có những gì cần thiết, và các quản lý không thể thêm cả triệu trường để hành người khác bằng báo cáo hay burndown chart
https://news.ycombinator.com/item?id=47616242
https://isolveproblems.substack.com/p/how-microsoft-vaporize...
GitLab cũng chẳng khá hơn là bao
Có vẻ họ có ngân sách vô hạn cho mấy chỉnh sửa UI ngớ ngẩn chẳng cải thiện gì thực tế, trong khi lại phớt lờ các lỗi nghiêm trọng trong bản phát hành
Khi tôi bắt đầu dùng GitLab lần đầu khoảng 8–9 năm trước thì nó rất tuyệt, và vài năm sau khi công ty chuyển sang GitHub, tôi thấy đó là một bước thụt lùi lớn
GitLab có rất nhiều tiện ích UX nhỏ và tuy có vài chỗ thô ráp nhưng nhìn chung vẫn có cảm giác được thiết kế tốt
Nhưng từ đó đến nay tình hình tệ hơn nhiều, UX đã thay đổi vô số lần và mỗi lần đổi dường như lại tệ hơn
Những chỗ thô ráp cũ không được sửa mà chỉ liên tục xuất hiện thêm chỗ thô ráp mới
Mấy năm gần đây rất khó nhớ ra có tính năng hữu ích nào được thêm vào hay cải thiện, và khi GitHub cũng đang lộn xộn như vậy thì tôi thật sự đã hy vọng GitLab sẽ trở thành lựa chọn tốt hơn rõ ràng và giành lấy thị trường, nên càng thấy đáng tiếc
Tôi mất mấy ngày loay hoay không biết nguyên nhân là gì, rồi đến bản cập nhật tiếp theo nó mới cảnh báo vấn đề để tôi chạy repair command và dọn dẹp lại
Đó chỉ là một máy chủ rất nhỏ, khoảng 10 người dùng và tối đa chừng 50 repository
GitHub, Bitbucket, Codeberg các thứ đều ổn, còn GitLab thì thật sự đầy lỗi, không thể cập nhật khóa SSH trên Firefox, mà cũng chẳng có dấu hiệu rõ ràng nào cho thấy đó là lỗi tương thích GitLab-Firefox
Tôi mất gần một tiếng mới nghĩ ra việc thử tải khóa SSH mới lên bằng Chrome, và từ đó xem như không muốn đụng vào GitLab nữa
Ghostty trở thành dự án mới nhất rời GitHub, nên tôi bắt đầu tự hỏi ai sẽ là người tiếp theo
Tôi không nghĩ đến thứ Tư tuần sau mọi người sẽ đồng loạt rời GitHub để tự dựng server Forgejo, nhưng việc người ta cuối cùng cũng bắt đầu cân nhắc rời GitHub là điều GitHub nên lo lắng
Kỹ sư phần mềm trung bình hoàn toàn không quan tâm đến VCS hay forge, và hiểu biết về cả hai cũng rất hời hợt
Với những người chỉ muốn làm việc xong rồi quay lại cuộc sống của mình, chuyện đó không quá quan trọng
Có phải chỉ mình tôi thấy vậy không, hay mọi thứ đã tệ hơn nhiều kể từ sau vụ MSFT mua lại?
Trong thời gian đó nó đã phình to đến mức nào? Gấp 10? Gấp 100? Hay hơn nữa?
Khi một công ty mua một thứ gì đó, vấn đề tiếp theo là ai sẽ sở hữu nó
Điều cốt lõi là trong công ty mới, ai là người chịu trách nhiệm “giữ cho nó tiếp tục tốt”, và kể cả khi những người từng làm việc đó trước đây vẫn ở lại sau sáp nhập thì vấn đề động lực vẫn là chuyện khác
Microsoft có vấn đề nghiêm trọng
Có cảm giác như họ lấy ít nhất 10 công ty dán lại bằng keo rồi gọi chung là Microsoft, và cũng có rủi ro danh tiếng rất lớn khi sự cố của bộ phận Xbox có thể ảnh hưởng xấu đến bộ phận công cụ hoặc ngược lại
Ở rất nhiều hạng mục họ thiếu tập trung, và sau khi ngừng các màn công bố với báo chí, họ đã cần một khoảnh khắc kiểu “service pack 2” để sửa đống nợ kỹ thuật khổng lồ như Everest này
Embrace, extend, and extinguish
Có người nói “GitHub user 1299, tham gia tháng 2 năm 2008”, vậy làm sao biết mình là GitHub user # bao nhiêu?
curl [https://api.github.com/users/YOUR_USER_HERE](<https://api.github.com/users/YOUR_USER_HERE>;)rồi xem id trong payload là được"id": 2851Hoặc xem mã nguồn HTML của avatar: https://avatars.githubusercontent.com/u/2851?v=4
Thành thật mà nói tôi cứ nghĩ mình phải ở mức vài triệu rồi
/u/#Tôi ở khoảng 4 triệu gì đó
Dựa trên thống kê hoạt động người dùng tôi đã tích lũy suốt gần 20 năm qua, tôi tin chắc mình thuộc top 1% người dùng, hoặc ít nhất cũng gần như vậy, xét về khối lượng công việc ổn định trong thời gian dài và việc hằng ngày viết ra phần mềm mà người khác thực sự dùng
Tôi cũng là người dùng GitHub từ khá sớm, dù không phải từ những ngày đầu tiên nhất, và dù các chỉ số của GitHub có đi xuống thì tôi vẫn đang phát hành đều đặn
Vì để viết phần mềm thì không cần GitHub
Bình luận của Hashimoto có vẻ bất ổn và tôi mong anh ấy tìm được sự bình tâm, nhưng nếu người nói không phải là anh ấy thì tôi nghĩ mình sẽ đọc bình luận đó và cho rằng có vấn đề gì đó, nên tôi cho rằng thực sự là vậy
Nếu không thì việc phán xét những người đang than phiền vì sự cố nghe khá trịch thượng và khó chịu
Kiểu đó tôi chỉ hay thấy trên Reddit
Việc có người bỏ lỡ trọng tâm theo kiểu “nó đâu có ngăn bạn code trên máy của mình” dễ đoán đến mức bài blog gốc đã nói trước về chính điểm đó
Đừng có tung ra những đòn công kích cá nhân ghê tởm như vậy về sức khỏe tinh thần của người khác
Nhưng đọc xong thì phản ứng cảm xúc của anh ấy quả thật có vẻ không hoàn toàn tương xứng với tình huống
Dù vậy, tùy quy mô dự án thì việc xử lý issue, làm review các thứ có thể khiến GitHub trở thành công việc toàn thời gian, và cũng không hiếm chuyện dùng mô tả PR cùng comment như một phần tài liệu thay cho commit message
Vì thế tính sẵn sàng của GitHub thật sự có thể là một sự cố rất lớn với nhiều công ty
Ngay lúc này vẫn đang có sự cố với GitHub API
Câu hỏi cốt lõi là đâu là giải pháp thay thế tốt nhất
Ngay cả bản miễn phí cũng không có phàn nàn lớn gì
Toàn bộ mã nguồn công khai thậm chí mirror lên đó cũng không sao
Nếu cần chỗ để chạy test thì hãy dựng hạ tầng riêng
Chưa bao giờ chuyện đó dễ như bây giờ, vậy tại sao lại phụ thuộc vào một hộp đen như thế?
Nhanh hơn GitLab rất nhiều