Tội ác đối với GitHub và phần mềm

 (eblog.fly.dev)
1 điểm bởi GN⁺ 22 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • GitHub được dùng như hạ tầng cốt lõi của phát triển phần mềm, nhưng bị đánh giá là độ tin cậy cơ bản đang lung lay vì sự cố xảy ra thường xuyên, trang chậm và lỗi hiển thị trên trình duyệt
  • Microsoft cho biết tải tăng vọt do agentic workflows, nhưng cũng ngày càng bị chỉ trích vì chính GitHub đã nhồi Copilot và các tính năng agent vào sản phẩm để thúc đẩy sử dụng
  • Trong thí nghiệm với kho lưu trữ tối thiểu, GitHub tải về 291 request, phản hồi nén 15MiB và 544.564 dòng sau giải nén, tương phản mạnh với 11 request của Codeberg
  • Ở phép đo phía frontend, GitHub dùng khoảng 69MiB heap ở trạng thái ổn định, còn trang pull request của rust-lang dùng 148MiB, bị đánh giá là lãng phí quá mức đối với một trang chủ yếu là văn bản
  • Kết luận là sự lãng phí của GitHub không chỉ là sản phẩm xuống cấp đơn thuần, mà là một thất bại phần mềm đặt tính năng AI và ưu tiên xoay quanh nhà đầu tư lên trước việc giải quyết vấn đề của người dùng

Độ tin cậy và ưu tiên của GitHub

  • GitHub được dùng như hạ tầng cốt lõi của phát triển phần mềm, nhưng bị nghi ngờ về độ tin cậy cơ bản do downtime, suy giảm hiệu năng và vấn đề tương thích trình duyệt
  • Lịch sử GitHub Status ghi nhận hàng chục sự cố mỗi tháng, và ngay cả theo trang trạng thái chính thức cùng tiêu chuẩn SLA cũng có những tình huống có thể xem là vi phạm
  • Dịch vụ này bị phê phán vì thường xuyên lỗi trên Firefox và Safari, trang bình luận và review pull request chậm, đồng thời mức dùng RAM và các đợt tăng vọt heap là quá mức
  • GitHub Actions bị xem là chậm và thiếu tài liệu; màn hình log được nêu là đã gây rò rỉ bộ nhớ và crash trình duyệt trong nhiều năm
  • Ngay cả hành vi cache của action cơ bản như setup-go cũng bị đánh giá là không có cơ chế vô hiệu hóa hoặc quá đơn giản
  • Có những trang như githubstars.com công khai quảng cáo bán sao, và câu “fake stars are highly related to malicious activities” từ bài báo của Carnegie Mellon cũng được trích dẫn
  • Mục tiêu mà GitHub nên hướng tới là một hệ thống phân tán hiệu năng cao, độ sẵn sàng cao, dung lượng lớn, nhưng sản phẩm thực tế bị đánh giá là ưu tiên tính năng AI và luồng agent hơn độ tin cậy cơ bản

Tải “agentic” và trách nhiệm của Microsoft

  • Trong bài ‘an update on github availability’, GitHub cho biết từ nửa sau tháng 12 năm 2025, agentic development workflows đã tăng tốc mạnh, còn việc tạo repository, hoạt động pull request, sử dụng API, tự động hóa và workload của repository lớn đều tăng nhanh
  • Cách giải thích này xem mức tăng tải như một hiện tượng bên ngoài, nhưng dẫn tới chỉ trích rằng GitHub và công ty mẹ Microsoft đã trực tiếp thúc đẩy sử dụng bằng cách nhồi AI và “agents” vào nhiều sản phẩm
    • Trên thanh trên cùng của gần như mọi trang GitHub đều có 3 nút AI, trong đó 2 nút chỉ để khởi chạy agent; nhiều trang còn có tới 4 nút
    • Ở khu vực góc trên bên phải của trang đích repository thông thường có 4 cách để chạy Copilot
    • GitHub đã nhiều năm trợ giá chi phí sử dụng công cụ để thúc đẩy mức độ chấp nhận; một bài chỉ trích cho rằng điều đó chẳng khác nào tự bỏ tiền tài trợ một cuộc từ chối dịch vụ phân tán nhắm vào chính mình
  • Microsoft giải thích rằng chỉ một pull request có thể chạm tới kho Git, kiểm tra khả năng merge, branch protection, GitHub Actions, tìm kiếm, thông báo, quyền hạn, webhooks, APIs, tác vụ nền, cache và cơ sở dữ liệu
  • Ở quy mô lớn, ngay cả những phi hiệu quả nhỏ cũng có thể dẫn đến hàng đợi sâu hơn, cache miss, tải DB, độ trễ lập chỉ mục và khuếch đại lưu lượng retry, nhưng sự phi hiệu quả của GitHub bị đánh giá không phải ở mức “nhỏ” mà là khổng lồ và áp đảo
  • Microsoft nói rằng “availability first, then capacity, then new features”, nhưng trong changelog công khai của GitHub, trong 30 ngày sau cập nhật đó, “copilot” xuất hiện 59 lần, “agent” xuất hiện 8 lần còn “performance” và “reliability” xuất hiện 0 lần trong ghi chú phát hành
    • Bộ lọc changelog có hẳn danh mục copilot, nhưng không có danh mục performance hay reliability
    • Visual Studio Code cũng được tích hợp trực tiếp với GitHub và các tính năng “agentic”, và bị chỉ trích vì vẫn thêm tính năng agent ngay cả khi các chức năng cơ bản như terminal tích hợp sẵn đang xuống cấp
  • Đoạn Microsoft nói đang giảm “unnecessary work”, cải thiện caching, cô lập dịch vụ quan trọng, loại bỏ điểm lỗi đơn lẻ, di chuyển các đường đi nhạy cảm với hiệu năng, giảm coupling ẩn, giới hạn blast radius và triển khai graceful degradation được diễn giải như một sự thừa nhận rằng thiết kế hệ thống đã sai

Vì sao frontend gợi ý vấn đề backend

  • Gốc rễ của vấn đề độ tin cậy ở GitHub nằm ở backend và cơ sở dữ liệu, nhưng không thể quan sát từ bên ngoài; thay vào đó có thể quan sát mã frontend như HTML, JavaScript và CSS được tải xuống mỗi lần
  • Tác giả cho rằng cũng như khi nhìn thấy chuột trong khu vực ăn uống của tiệm pizza thì khó tin nhà bếp sạch sẽ, sự mục nát dễ thấy ở frontend của GitHub gợi ý có vấn đề ở backend, dù không thể chứng minh
  • Các trang đích repository của GitHub, GitLab và Codeberg gồm danh sách liên kết, các yếu tố UX nhỏ, nút bấm, tab và ô tìm kiếm, gần như không có thành phần đắt đỏ như media tương tác hay hình ảnh
  • Những trang như vậy lẽ ra phải chạy nhẹ trên gần như mọi máy tính hay điện thoại, ngay cả với kết nối internet không tốt; bài viết cho biết GitHub trước đây thực sự đã hoạt động như vậy cả trên iPhone 4 và kết nối 3G
  • Nếu chức năng là như nhau, đoạn mã tốt nhất được định nghĩa là đoạn mã dùng ít băng thông mạng, thời gian CPU và RAM nhất, đồng thời có ít lỗi nhất
  • Không thể biết trực tiếp số lượng bug của frontend, nhưng các nghiên cứu lịch sử cho thấy số bug thường tỷ lệ với số dòng mã
    • Steve McConnel, Code Complete, 2nd Ed (2004) được trích dẫn rằng mức lỗi trung bình của ngành trong phần mềm bàn giao là 1 đến 25 lỗi trên mỗi 1.000 dòng mã
    • Microsoft Applications Division được trích dẫn là đã trải qua 10 đến 20 lỗi trên mỗi 1.000 dòng mã trong quá trình kiểm thử nội bộ, và 0,5 lỗi trên mỗi 1.000 dòng mã ở sản phẩm phát hành

Thiết kế thí nghiệm và cách thu thập

  • Để giảm biến gây nhiễu, tốc độ internet được giới hạn ở kết nối “fast 3G”
    • Đây là thiết lập nhằm giảm ảnh hưởng của biến động điều kiện mạng và mô phỏng trải nghiệm khách hàng GitHub trong các tình huống kém lý tưởng hơn như khu vực nông thôn
  • Cả ba dịch vụ đều dùng cùng một repository tối thiểu ghsucks
    • Một nhánh duy nhất master
    • Một tệp duy nhất README.md
    • 0 yếu tố bổ sung như issue, tag, v.v.
  • Dùng cùng một trình duyệt và cùng một máy tính
    • Firefox
    • Apple Macbook Pro M5 Max
    • 48GiB RAM
  • Khảo sát bốn loại trang trên mỗi dịch vụ
    • Trang “landing”: bố cục mã
    • Trang “pull requests” hoặc “merge requests”
    • Trang “issues”
    • Trang “settings”
  • Thu thập HTTP Archive (HAR) với trạng thái cache sạch để phân tích request mạng, và sau khi tải xong thì thu thập heap snapshot để lấy ước tính mức dùng RAM ở trạng thái ổn định
  • Phân tích HAR dùng anhar do tác giả tự viết, phân tích hỗ trợ nén dùng testcompress, và đối chiếu chéo bằng pagespeed.web.dev

Mức sử dụng heap và lãng phí bộ nhớ

  • Mức sử dụng heap của trang kho lưu trữ mặc định được đo là GitHub 69MiB, GitLab 68MiB, Codeberg 14MiB, eblog.fly.dev 1.3MiB
  • Việc render trang issue đầu tiên của https://github.com/rust-lang/rust/pulls sử dụng 148MiB RAM
  • 148MiB là nhiều bộ nhớ hơn cả iPhone đời đầu, và bị đánh giá là lãng phí cực độ đối với một trang chủ yếu là văn bản với vài liên kết
  • Bộ nhớ của các thiết bị được đưa ra để so sánh gồm Apple iphone 1 128MiB, iphone 4 512MiB, Sony playstation 2 32MiB, Nintendo wii 88MiB, v.v.

So sánh lượng request và quy mô phản hồi

  • anhar là chương trình Go phân tích HAR JSON, tự động format HTML·CSS·JavaScript của phản hồi bằng deno fmt, rồi tính kích thước request·response, tổng theo MIME, thời gian tải và số dòng phản hồi
  • Các chỉ số chính là kích thước request, kích thước phản hồi rút gọn thực tế nhận được, kích thước phản hồi mở rộng và số dòng sau khi áp dụng deno fmt, thời gian tải HTML cơ bản là Content-Load, và thời gian tải toàn bộ nội dung là Load
  • Trang kho lưu trữ Codeberg được đo với tổng cộng 11 request, request 9KiB, phản hồi 1MiB, phản hồi mở rộng 1MiB, mở rộng 3.480 dòng, Content-Load 2.934s, Load 3.172s
  • Trang kho lưu trữ GitHub được đo với 291 request, request 178KiB, phản hồi rút gọn 15MiB, phản hồi mở rộng 22MiB, mở rộng 544.564 dòng, Content-Load 843ms, Load 21.330s
    • application/javascript: 214 request, phản hồi 12MiB, phản hồi mở rộng 19MiB, mở rộng 481.849 dòng
    • text/css: 42 request, phản hồi 2MiB, mở rộng 60.016 dòng
    • GitHub pulls: 266 request, rút gọn 14MiB, mở rộng 20MiB, mở rộng 487.922 dòng, Content-Load 592ms, Load 6.754s
    • GitHub settings: 255 request, rút gọn 14MiB, mở rộng 20MiB, mở rộng 486.067 dòng, Content-Load 778ms, Load 6.963s
  • GitLab nhỏ hơn GitHub nhưng vẫn nặng
    • Kho lưu trữ GitLab: 78 request, phản hồi 8MiB, mở rộng 101.682 dòng, Content-Load 6.880s, Load 12.941s
    • GitLab merge_requests: 65 request, phản hồi 7MiB, mở rộng 90.567 dòng, Content-Load 6.947s, Load 12.096s
    • GitLab edit: 117 request, phản hồi 7MiB, mở rộng 71.916 dòng, Content-Load 6.964s, Load 13.302s
  • GitHub lấy về khoảng 540K dòng mã và dữ liệu ngay cả để hiển thị một kho lưu trữ trống, và có so sánh rằng con số này còn nhiều hơn DOOM 35K dòng, Windows Quake 120K dòng, MS-DOS 4.0 332K dòng, Zig toolchain 460K dòng
  • Cấu trúc mà mỗi trang riêng lẻ tải 40 tệp CSS và hàng trăm JavaScript bị đánh giá là có vấn đề
  • Về lý thuyết, việc chia nhỏ chunk của Webpack có thể tách chức năng cốt lõi và chức năng tùy chọn, đồng thời có lợi cho caching và CDN, nhưng ở đây nó được diễn giải là dẫn đến tải chậm hơn vì mỗi tệp đều cần một HTTP request độc lập
  • Việc phải chờ 22 giây để xem một trang trống là khó có thể chấp nhận, và ngay cả trên mạng cáp quang hơn 1GiB/s cùng bộ xử lý tiêu dùng hiệu năng cao thì vẫn bị đánh giá là mất hơn 1 giây để kho lưu trữ trở nên phần nào có thể sử dụng

So sánh hỗ trợ nén

  • Nén được nêu là một cách hữu ích để giảm tải cho client, server và các chặng trung gian
  • gzip là tiêu chuẩn nén đã được kiểm chứng và mọi website nên hỗ trợ, còn zstd có đặc tính hiệu năng tốt nhưng là cách hiện đại hơn nên mức hỗ trợ được xem là “có thì tốt”
  • testcompress là chương trình Go kiểm tra xem URL có hỗ trợ nén gzip và zstd hay không, và nếu không hỗ trợ thì sẽ tự nén phần thân phản hồi để cho thấy mức tiết kiệm tiềm năng
  • eblog.fly.dev/startingsystems3.html: encoding được hỗ trợ zstd gzip, bản gốc 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
  • github.com/ef0xa/ghsucks: encoding được hỗ trợ gzip, bản gốc 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks: encoding được hỗ trợ gzip, bản gốc 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks: encoding được hỗ trợ n/a, bản gốc 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

Kết quả PageSpeed trên di động

  • Trong phép đo di động của pagespeed.web.dev, Codeberg đạt PASS với First Contentful Paint 1.2s, Largest Contentful Paint 1.3s, Interaction to Next Paint 86ms
  • eblog.fly.dev đạt PASS với First Contentful Paint 1.1s, Largest Contentful Paint 1s, Interaction to Next Paint N/A
  • GitHub bị FAIL với First Contentful Paint 1.8s, Largest Contentful Paint 2.1s, Interaction to Next Paint 242ms
  • GitLab bị FAIL với First Contentful Paint 2.1s, Largest Contentful Paint 2.4s, Interaction to Next Paint 243ms

Đánh giá theo từng dịch vụ

  • GitHub

    • Tải về khoảng 300 tệp, khoảng 550.000 dòng mã và dữ liệu, với số lỗi ước tính được nêu là 550
    • Content-Load khoảng 800ms, Load tổng thể khoảng 7s, heap ở trạng thái ổn định được tóm tắt là khoảng 69MiB
    • Hỗ trợ gzip nhưng không hỗ trợ zstd
    • Được chấm F, bị đánh giá là có độ nặng mã rất lớn
    • Có ý kiến chỉ ra rằng GitHub tải tất cả theme trên mọi trang bất kể có dùng hay không
    • Vì pagespeed.web.dev cho thấy 528KiB JavaScript và CSS hoàn toàn không được sử dụng, nên có thể bắt đầu cắt giảm từ phần này
    • Nếu buộc phải ở lại GitHub, có đề xuất cho rằng họ đang vi phạm SLA của chính GitHub và nên gửi ticket hỗ trợ để yêu cầu hoàn tiền

  • GitLab

    • Content-Load khoảng 7s, Load khoảng 13s, tải về hơn 70 tệp với 7MiB, khoảng 10.000 dòng
    • Heap ở trạng thái ổn định khoảng 68MiB, hỗ trợ gzip nhưng không hỗ trợ zstd
    • Được chấm D+, bị đánh giá là không lãng phí như GitHub nhưng vẫn tải quá nhiều tài nguyên và không sử dụng hiệu quả
    • Tải hơn 1MiB JavaScript và CSS nhưng có phần thực tế hoàn toàn không được dùng, còn trong phần mã được dùng cũng có chunk 3MiB khiến riêng việc parse đã mất 255ms
    • Trang đích không cần đến 55.000 dòng CSS, và cả CSS lẫn JavaScript đều được cho là có thể giảm xuống còn khoảng 1/10 mức hiện tại

  • Codeberg/Forgejo

    • Content-Load là 2,9s, Load là 3,1s, tải về 1MiB trong 11 tệp, khoảng 1.100 dòng
    • Heap ở trạng thái ổn định khoảng 14MiB, không hỗ trợ cả gzip lẫn zstd
    • Được chấm C+, bị đánh giá là có nền tảng cơ bản nhưng thiếu sự chú ý đến chi tiết và kinh nghiệm
    • Việc không minify HTML là vấn đề nhỏ, nhưng không hỗ trợ nén bị xem là thiếu sót lớn
    • Phần lớn JavaScript và CSS không cần cho việc render trang, nhưng vấn đề là chúng được tải theo cách chặn render
    • Có đề xuất gộp payload JavaScript và CSS để giảm số lượng request, đồng thời hỗ trợ nén gzip và zstd cho payload HTTP bao gồm cả HTML
    • Vì là phần mềm tự do, nên khả năng chuyển sang instance khác hoặc tự host được nêu là một ưu điểm

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html được đo với Content-Load 76ms, Load 1,1s, 5 tệp 766KiB, khoảng 3.800 dòng
    • Tệp HTML đơn lẻ có dung lượng 576KiB và được nén bằng zstd xuống còn khoảng 70KiB
    • Heap ở trạng thái ổn định khoảng 11MiB, hỗ trợ cả zstd và gzip
    • Được chấm A-, nhìn chung là tốt nhưng HTML bị đánh giá là phình to và lặp lại ngay cả khi đã tính đến nén, và một trang lẽ ra có thể xong trong một request lại cần tới 5 request

Không chỉ là sản phẩm bị xuống cấp, mà là vấn đề chi phí

  • “enshittification” được tóm lược là quá trình một sản phẩm ban đầu có lợi cho người dùng và khách hàng doanh nghiệp, sau đó trở nên bất lợi cho người dùng, rồi tiếp tục bất lợi cả với khách hàng doanh nghiệp để ngày càng có lợi cho bên vận hành
  • Microsoft và GitHub cũng không hoàn toàn tách rời khỏi Embrace, Extend, Extinguish, nhưng vấn đề ở đây được xem là khác ở chỗ nó tạo ra chi phí không chỉ cho người dùng và khách hàng doanh nghiệp mà cả cho Microsoft
  • Codebase phình to trực tiếp làm tăng chi phí máy chủ và băng thông, đồng thời gián tiếp tiêu tốn thời gian kỹ sư để duy trì một codebase bất ổn và cồng kềnh
  • Nếu giả định GitHub có khoảng 800 kỹ sư, mỗi người làm 40 giờ mỗi tuần và 48 tuần mỗi năm, thì tương đương 1.536.000 giờ-kỹ sư mỗi năm
  • Phần lớn vấn đề frontend được cho là chỉ cần làm theo khuyến nghị của pagespeed thì một kỹ sư giỏi có thể sửa hoặc giảm nhẹ trong vòng một tuần
  • Lý do các cải thiện ở tầng thấp dù có thể tiết kiệm chi phí vẫn bị bỏ mặc được lý giải là một trong ba khả năng: thờ ơ, cực kỳ kém năng lực, hoặc bị chặn bởi kiểu lãnh đạo xoay quanh AI và nhà đầu tư
  • Phần mềm được mô tả là một công cụ mạnh mẽ và đẹp đẽ vì một khi đã được viết đúng, nó có thể được sao chép hoàn hảo, vĩnh viễn và miễn phí để mọi người cùng sử dụng
  • Kết luận được đưa ra là sự lãng phí và kém năng lực của GitHub và các dịch vụ tương tự không chỉ là một sản phẩm tồi, mà là một tội ác đối với phần mềm

Bài viết liên quan

1 bình luận

 
GN⁺ 22 giờ trước
Ý kiến trên Lobste.rs

  • Sẽ hay hơn nếu đưa cả Trac và Sourcehut vào phép so sánh này

  • 4 nút AI agent thì buồn cười, và các con số tương đối trong bài cũng thú vị, nhưng dù tôi hoàn toàn không có ý bênh GitHub, một số chi tiết trong bài lại thiếu ngữ cảnh nên có vẻ chưa đủ để nâng đỡ lập luận của tác giả
    Mức dùng bộ nhớ nhàn rỗi có thể là tín hiệu cho thấy GitHub làm nhiều việc hơn Codeberg, nhưng rất khó rút ra kết luận có ý nghĩa khi so sánh lượng RAM tuyệt đối trên một máy tính 48GB RAM với máy tính dẫn đường Apollo
    Việc định dạng lại một JavaScript bundle đã minify để ước lượng số dòng code, rồi đem so với số dòng của một dự án Zig không tính dependency, cũng là so táo với cam. Cứ thử decompile file thực thi Zig xem ra bao nhiêu dòng
    Tôi cũng không hiểu khuyến nghị rằng Codeberg “nên gộp payload JavaScript và CSS để giảm số lượng request”. Nhìn cách nói về “phần overhead bổ sung” của request HTTP, tôi còn nghi ngờ tác giả có biết HTTP/2 hay không
    Tôi còn nhiều điều muốn nói về hiệu năng trang web, nhưng sẽ để dành cho một bài khác; với một góc nhìn tốt hơn về chủ đề tương tự, tôi khuyên nên đọc lại bài về web bloat năm 2017 của Danluu: https://danluu.com/web-bloat

  • Nếu tác giả đang theo dõi, có thể nên xem qua cuộc tranh luận giữa Casey Muratori và Uncle Bob. Người trước đã phát hiện ra một thứ rất thú vị làm tụt hiệu năng
    “Tôi không cưỡng lại được nên đã mở bản capture hiệu năng của Chrome lên, và tôi biết thủ phạm là ai :) đó là ‘emoji picker’!”
    “Tôi chỉ lướt qua code thôi, nhưng có vẻ vấn đề là mỗi khi bạn nhập ký tự, ‘emoji picker’ lại quét ngược trở lại để kiểm tra xem thứ vừa gõ có phải emoji không”
    Kinh khủng. Dù vậy, trong trường hợp này, thủ phạm có thể không phải code frontend của GitHub mà là trình duyệt dựa trên Chromium

  • Cách diễn đạt “Codeberg là sản phẩm phụ thuộc vào quyên góp độc lập và tình nguyện viên rảnh rỗi” là không chính xác
    Codeberg phụ thuộc vào thành viên. Không chỉ về tiền hội phí mà còn về mặt chính sách; hiện tại hội phí vẫn chưa đủ để thuê nhân viên toàn thời gian nên họ phụ thuộc nhiều vào tình nguyện viên, nhưng theo tôi hiểu thì cũng có nhà thầu
    Tôi không theo dõi Codeberg quá sát (tôi thích phía sourcehut hơn), nhưng việc đây là một hợp tác xã là một phần cốt lõi trong giá trị mà họ đưa ra. Họ cũng cố gắng công khai minh bạch chi tiêu. Ví dụ: https://blog.codeberg.org/codebergs-budget-of-2026.html
    Nếu bạn đang dùng Codeberg, có lẽ nên cân nhắc tham gia làm thành viên ngay bây giờ: https://join.codeberg.org/

  • Tôi thực sự ghét GitHub. Vấn đề của tôi không phải uptime, mà là nó chậm vô lý và ngốn bộ nhớ khủng khiếp. “Diff cỡ này không được hiển thị mặc định” à, nghiêm túc vậy sao
    Nó cũng phá hỏng những luồng làm việc phát triển hoàn toàn hợp lý. Rebase một PR thì feedback review và comment biến mất, squash commit thì feedback review và comment cũng biến mất
    Dù có link đến một comment cụ thể đi nữa, nếu commit đó biến mất thì comment cũng biến mất theo \o/
    Có bug fix thì họ bảo tạo PR, nhưng kể cả khi bug đó đã được sửa bởi thay đổi khác, vì PR và bug tồn tại cùng một cấp nên PR chết cứ nằm mãi trong hàng đợi review
    Muốn biết commit này đã sửa bug nào thì nó chỉ cho xem lịch sử PR. Kiểu như hãy nhìn PR chứ đừng nhìn bug; muốn biết bug nào thì tự đi tìm bug đi

    • Bản thân khái niệm “pull request”, cũng như git, xuất phát từ quy trình phát triển Linux kernel. Đó là luồng công việc trong đó bạn yêu cầu maintainer của kernel “pull” bản vá của mình vào mainline
      GitHub đã làm quy trình này dễ hơn bằng nút “fork”, thêm username tập trung để nó mang tính “social” hơn, rồi gắn thêm issue tracker và wiki để thống trị thế giới. Xét về kinh doanh thì đúng là thiên tài
      Nhưng toàn bộ luồng công việc này vẫn được thiết kế cho phát triển mã nguồn mở, nơi những người tách rời nhau yêu cầu người khác “pull” patch của mình
      Tôi không hiểu tại sao một đội phát triển gắn kết chặt chẽ, nơi cơ chế thực tế là “thảo luận về branch và phê duyệt merge”, lại phải dùng “pull request”. Pull từ cái gì? Nó ở cùng repository, và thay đổi thì đã được push rồi mà
      Bỏ qua chuyện thuật ngữ, việc thiếu thay đổi tích lũy, comment ổn định, và diff theo tập thay đổi là vô lý
      Xin lỗi vì lại đăng một bài than phiền dài dòng về GitHub. Có lựa chọn nào tốt hơn không? Tất nhiên là chẳng thể ép ai dùng được, nhưng mà…

  • Tôi đã thấy vài lần phản ứng kiểu “đồ thị không có nhãn trục hay từng điểm dữ liệu riêng lẻ thì lúc nào cũng đáng nghi” nhắm vào những đồ thị GitHub công bố
    Trên đồ thị có ghi giá trị cực đại, nên có thể ước lượng bằng mắt rằng các mức giữa trên trục y lần lượt khoảng 45M, 0.7B và 10M. Tất nhiên là trừ khi họ lén dùng log scale và tải tăng không phải 100000 lần
    Tôi sẽ không gọi một biểu đồ tệ là “đáng ngờ”, chỉ xem đó là truyền đạt kém thôi. Cá nhân tôi lúc nào cũng thích output ggplot thô hơn
    Tôi đồng ý với cảm xúc chung, nhưng hơi khó theo ở đoạn nói về ngựa béo và cái bàn lớn. Dù vậy, nếu tôi liệt kê hết mọi lỗi của GitHub, chắc tôi cũng sẽ phát điên và bắt đầu mơ mình cưỡi con ngựa béo đi vào hoàng hôn
    Tôi cũng từng bắt đầu lập danh sách tương tự, rồi bỏ cuộc khi số vấn đề UX/hiệu năng lên đến khoảng 12 cái. Tôi thích sự phân tích kỹ lưỡng của bài này và hy vọng đội GitHub sẽ xem xét nghiêm túc
    Như tôi đã nói trước đây, Microsoft nên phân bổ một số kỹ sư hiệu năng cho GitHub. Chừng nào chỉ số hiệu năng chưa thực sự được đưa vào KPI cốt lõi thì sự phình to này sẽ còn tiếp diễn và các nền tảng khác sẽ ngày càng hấp dẫn hơn. Nếu GitHub có CEO tiếp theo, tôi hy vọng người đó sẽ ưu tiên việc này

    • Bạn đang giả định trục y của đồ thị bắt đầu từ 0. Trong những biểu đồ kiểu doanh nghiệp thế này, rất nhiều trường hợp không phải vậy
      Họ thường tuyên bố “tăng trưởng khổng lồ”, đường biểu đồ thì chéo hẳn qua toàn bộ vùng hình, nhưng trục y thực ra chỉ chạy từ 100 đến 101

  • Tôi đồng ý với ý rằng “log GitHub Actions bị rò rỉ bộ nhớ làm chết trình duyệt của tôi suốt nhiều năm, và đến giờ vẫn chưa có cách đơn giản để chỉ pipe stdout sang đâu đó”
    Đáng tiếc là Forgejo cũng thừa hưởng chuyện này. Có lúc tôi nhận được thông báo build thất bại và muốn xem nhanh trên điện thoại, nhưng trong khá nhiều trường hợp trình duyệt trên điện thoại thậm chí không tải nổi phần output

  • Khi bấm vào bài này, tôi hoàn toàn tưởng đây sẽ lại là một bài than phiền khác về uptime của GitHub, nhưng hóa ra đây là một bài đánh giá điềm tĩnh và hợp lý về các vấn đề hiện tại của GitHub, GitLab và Codeberg, lại còn đề xuất cả giải pháp, nên tôi khá bất ngờ theo hướng tích cực
    Sẽ hay hơn nếu đưa cả Tangled vào phần so sánh
    Tác giả nên viết thêm chút CSS để trang này đọc được trên di động. Tôi đã phải dùng chế độ đọc của trình duyệt
    Điểm duy nhất tôi không đồng ý là khẳng định không trang nào nên tải quá một file JavaScript/CSS
    Nếu 550 nghìn dòng JavaScript đó đều nằm trong một file, thì parse và thực thi sẽ còn mất thời gian hơn nhiều. CSS thì có thể bundle được, nhưng ví dụ như mô hình một common chunk cộng một chunk theo từng route vẫn có thể hữu ích. Cách tiếp cận này hay thứ gì tương tự có lẽ sẽ còn được dùng rộng rãi

  • Không thể đọc nổi trang này
    Và nếu ghét GitHub thì đừng dùng nó. Tôi ngạc nhiên là người ta có thời gian để gom một danh sách than phiền dài như thế. Hoặc là họ được trả tiền để dùng nó, hoặc là cứ dùng thứ khác đi