Chúc mừng kho lưu trữ thứ 1 tỷ được tạo trên GitHub
(github.com/AasishPokhrel)- Người dùng GitHub jonmagic chúc mừng việc tạo kho lưu trữ thứ 1 tỷ của GitHub trong Issue #1, đồng thời cho biết kho lưu trữ
shitmang ID này - Phản hồi
curl -sđược đưa ra làm bằng chứng có chứa id1000000000,node_idR_kgDOOO5rKAA,nameshit,full_nameAasishPokhrel/shit - Luồng bình luận chủ yếu xoay quanh các lời chúc mừng và trò đùa tận dụng tên kho lưu trữ cùng emoji 💩; bài viết ban đầu nhận được hàng nghìn phản ứng 👍·😄·🎉
- jonmagic để lại liên kết tài liệu GitHub, nói rằng chủ sở hữu kho lưu trữ có thể dùng khóa cuộc trò chuyện hoặc hủy đăng ký nếu cần
- Ngày 28/6/2025, chủ sở hữu kho lưu trữ đã giới hạn cuộc trò chuyện cho collaborator và khóa lại; cùng ngày, một bình luận bị xóa
shit được chỉ ra là kho lưu trữ thứ 1 tỷ
- Tiêu đề Issue là
Congratulations on creating the one billionth repository on GitHub!, với nội dung chúc mừng việc tạo kho lưu trữ thứ 1 tỷ trên GitHub - jonmagic chúc mừng người tạo kho lưu trữ và đưa ra một phần kết quả lệnh gọi API sau làm căn cứ
curl -s https://api.github.com/repositories/1000000000- Phản hồi có chứa
id: 1000000000,node_id: R_kgDOOO5rKAA,name: shit,full_name: AasishPokhrel/shit
- Thông điệp chúc mừng bao gồm câu đùa dựa trên tên kho lưu trữ, theo kiểu “hy vọng bạn có cơ hội tạo ra một 💩 thật tuyệt”
Phản ứng bình luận và luồng đùa vui
- Các bình luận ban đầu phần lớn là lời chúc mừng và chơi chữ
- “Rất mong chờ xem bạn sẽ tạo ra 💩 tuyệt vời nào”
- “Không thể chờ đến lúc 💩 này nổi lên”
- “Tôi sẽ fork cái này”
- “Để lại bình luận trước khi issue này bị khóa”
- MangoCubes để lại phản hồi rằng họ yên tâm vì jonmagic là nhân viên GitHub
- jordigh nhại lại kiểu bình luận thường thấy trong issue bằng câu như “có lịch dự kiến sửa lỗi hoặc cách workaround nào không”
- Sau đó tiếp tục xuất hiện các bình luận ngắn như
💩,sssssssshit, “peak shit”
Hướng dẫn về việc thông báo tăng đột biến
- jonmagic hướng dẫn
AasishPokhrelrằng nếu cần thì có thể khóa cuộc trò chuyện hoặc hủy đăng ký - Hai liên kết tài liệu được để lại kèm theo là
Quy mô tham gia và phản ứng
- Nội dung issue gốc hiển thị hàng nghìn phản ứng
- 👍 4524
- 😄 2116
- 🎉 2638
- ❤️ 945
- 🚀 1201
- 👀 611
- Ở giữa danh sách bình luận có hiển thị rằng còn 1136 mục nữa, nên chỉ một phần bình luận được hiển thị
- Metadata hiển thị một số người tham gia và
+1092
Trạng thái khóa và sau đó
- Ngày 28/6/2025, chủ sở hữu kho lưu trữ đã khóa cuộc trò chuyện và giới hạn cho collaborator
- Cùng ngày, một bình luận của
luckydonaldbị xóa - Ở cuối issue có hiển thị thông báo rằng cần đăng ký hoặc đăng nhập để tham gia cuộc trò chuyện trên GitHub
1 bình luận
Ý kiến trên Hacker News
Làm tôi nhớ đến changeset thứ 100 triệu của OpenStreetMap
Một vài người, có cả tôi, đã thử nhắm đến nó cho vui, nhưng cuối cùng nó lại thuộc về một người đang miệt mài vẽ bản đồ châu Phi, chứ không phải ai cố tình săn cột mốc đó
Nhìn lại thì đó là một cái kết ấm áp hơn nhiều, và người đó trước đây còn từng được đề cử làm ứng viên trên OSM
Với OpenStreetMap, mọi thứ đều là dữ liệu vận hành thực tế nên rất khó tạo dữ liệu rác bừa bãi, vì vậy có vẻ khả năng commit thứ N là một việc làm ngẫu hứng của ai đó sẽ cao hơn
Với GitHub thì đây cũng là một thành tựu thú vị :)
Nếu muốn đọc thêm về cột mốc OSM, đây là bài blog chính thức: https://blog.openstreetmap.org/2021/02/25/100-million-edits-...
Phần tổng hợp của tôi về hoạt động changeset khi đó: https://www.openstreetmap.org/user/LucGommans/diary/395954
Cuối cùng không biết anh ấy đã làm được bằng cách nào, nhưng cả đội còn tổ chức một bữa tiệc nhỏ để kỷ niệm thành tích đó
Chắc khoảng 15 năm trước rồi; hồi đó tôi có cảm giác công việc trong ngành công nghệ vui hơn bây giờ
Tuyệt thật! Ngay cả OpenAPI Spec nội bộ của GitHub cũng chỉ còn hơn 1 tỷ repository nữa là tràn int32
Với workflow run ID thì chuyện đó đã xảy ra rồi
https://github.com/github/rest-api-description/issues/4511
Với tốc độ tăng khi đó, chỉ vài tháng nữa là giá trị khóa chính sẽ tràn, nên chúng tôi phải khá gấp rút thực hiện dự án nâng ID lên 64-bit để tránh thảm họa
Con số này xung đột với cách triển khai LuaRocks trên LuaJIT [1] [2], khiến pipeline CI/CD và workflow cá nhân của một số người dùng bị lỗi, gây khá nhiều phiền toái
Vấn đề được xử lý khá nhanh, nhưng đó là một chuyện thú vị
[1] https://github.com/luarocks/luarocks/issues/1797
[2] https://github.com/openresty/docker-openresty/issues/276
Giá mà tôi vẫn còn ở Apple
Phần lớn mọi người ở đây chắc đều biết Apple từ lâu đã dùng một công cụ nội bộ tên là Radar
Mỗi Radar có một ID, tức là số bug
Những Radar như bug #1.000.000 khá đặc biệt
Trừ khi ai đó lỡ tay làm cả đội thất vọng, thường đó là một Radar giả chứa đầy trò đùa nội bộ
Chỉ mở một cái ra thôi cũng đã đủ rồi, vì Radar có thể tham chiếu đến Radar khác, nên thường từ đó bạn sẽ rơi vào một rabbit hole và tha hồ khám phá
Thật ngu ngốc khi hồi còn có cơ hội tôi đã không chụp lại hoặc in ra vài cái
Đáng tiếc là vài năm trước, khi gần đến một con số tròn nào đó, những người muốn giành ID đó đã chạy script khiến hệ thống rơi vào trạng thái từ chối dịch vụ
Vì vậy giờ hệ thống sẽ bỏ qua các ID gần những con số tròn lớn :(
Có lẽ ở đây có một bài học nào đó về thiết kế schema
Nhân tiện nói về ID repository của GitHub, repository đầu tiên nằm ở đây
https://api.github.com/repositories/1
https://github.com/mojombo/grit
Repository thứ 1000 thì đã biến mất
Có lẽ họ đã dùng script kiểm tra lặp lại https://api.github.com/repositories/999999999 rồi tạo repository mới ngay khoảnh khắc nó xuất hiện
Vì repository có thể chỉnh sửa được, cũng có thể họ đã tạo dư vài cái rồi xóa những cái không đúng số
Nhìn các repository khác mà tác giả tạo hôm qua, có vẻ “yep” là con số kỳ diệu, còn “shit” là lời thừa nhận đã trượt
Có ai còn nhớ D666666 của Facebook không?
Đó là một lần chuyển đổi mã khổng lồ, và tác giả đã dùng kỹ thuật tương tự để lấy được con số cụ thể đó
Tôi không hiểu vì sao lại mặc định rằng người này cố tình giành repository đó
Nói nghiêm túc thì hơi ngạc nhiên là GitHub lại để việc tính tốc độ tạo repository mới dễ đến vậy
Thông tin kiểu này thường không phải là bí mật doanh nghiệp sao?
Tôi không biết có thể dùng nó theo cách nào gây bất lợi cho GitHub
Tôi hiểu là nhiều công ty mặc định không công bố bất kỳ thông tin nào trừ khi bị bắt buộc
Trước đây tôi từng theo dõi tốc độ tăng trưởng của nhiều website theo cách này
Theo một cách nào đó thì phần đó còn thú vị hơn
Tôi tò mò liệu AasishPokhrel có tạo repository này để trở thành repository thứ 1 tỷ hay không
Từ ngày 17/5 đến 10/6 thì không có hoạt động nào
Tôi không biết có thể tính tốc độ tạo repository rồi tạo đúng lúc để khớp với số mong muốn hay không
Cứ tiếp tục tạo repository cho đến khi cái thứ 1 tỷ xuất hiện, rồi xóa các cái trước đó là được
Với GitHub API thì cực kỳ đơn giản
Vấn đề chỉ là giới hạn tốc độ và những người khác đang tạo repository cùng lúc, nên cuối cùng vẫn là chuyện may rủi
Hy vọng cậu ấy đưa điều này thật nổi bật vào CV và tìm được một sự nghiệp tốt trong lĩnh vực phát triển
Repository đó đã bị đổi tên và giờ có vẻ chuyển hướng tới https://github.com/AasishPokhrel/repository/
Không hay lắm :-(
Tôi tự hỏi nếu tính cả các máy chủ Forgejo và GitLab cục bộ thì tổng số repository sẽ là bao nhiêu
Bao gồm cả Subversion, Mercurial, những người bạn khác của git, và cả kẻ thù của nó nữa
Không biết đã có ai làm công cụ tìm kiếm cho những thứ này chưa?
Sẽ tốt nếu có thể tìm một từ như “a” để ước lượng quy mô đại khái
Lợi thế lớn của GitHub tập trung hóa dường như luôn là mọi người thực sự có thể tìm thấy code của tôi
Sau khi Microsoft mua lại GitHub, tôi từng nghĩ đến việc làm một công cụ tìm kiếm, nhưng rồi không làm vì cảm thấy không kham nổi phần marketing và sẽ thành công cốc
Gần đây tôi đã đưa vài dự án lên Codeberg và lại nghĩ liệu có đáng thử lại không, nhưng có thể ai đó đã đi trước rồi
https://docs.gitlab.com/api/projects/#list-all-projects — vì lý do kỳ lạ nào đó, GitLab có vẻ gọi là project chứ không phải repository
https://codeberg.org/api/swagger#/repository/repoGetByID — được liên kết từ trang Forgejo.org nên có lẽ cả Forgejo và Codeberg đều giống nhau
Và người bạn đó https://gitea.com/api/swagger#/repository/repoGetByID
Heptapod là một “friendly fork” của GitLab CE nên API cũng hoạt động giống vậy: https://heptapod.net/pages/faq#api-hgrc
Tiếp theo có lẽ phải lập chỉ mục các instance GitLab theo từng dự án: Gnome, GNU (nếu một ngày nào đó mở lại), tình hình bên Savannah, có lẽ Sourceforge, và có thể cả sourcehut nữa
Nếu trúng xổ số, tôi muốn tài trợ vận hành các instance sourcegraph thời còn dùng giấy phép Apache trên nhiều nơi nhất có thể, rồi tặng các snapshot đó cho Internet Archive
Tìm kiếm repository hiện vẫn còn khá hạn chế, gần như chỉ có tìm kiếm toàn văn URL hoặc tìm kiếm một số ít file metadata như package.json
https://ohshitgit.com