อาชญากรรมต่อ GitHub และซอฟต์แวร์

 (eblog.fly.dev)
1 คะแนน โดย GN⁺ 22 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GitHub ถูกใช้งานราวกับเป็นแกนหลักของโครงสร้างพื้นฐานสำหรับการพัฒนา แต่ก็ถูกมองว่าความน่าเชื่อถือพื้นฐานเริ่มสั่นคลอนจากอินซิเดนต์ที่เกิดบ่อย หน้าเว็บที่ช้า และการแสดงผลในเบราว์เซอร์ที่พัง
  • Microsoft ระบุว่าภาระงานพุ่งสูงจาก agentic workflows แต่ก็มีเสียงวิจารณ์เพิ่มขึ้นว่า GitHub เป็นฝ่ายยัดฟีเจอร์ Copilot และ agent เข้าไปเองเพื่อชักจูงให้ผู้ใช้ใช้งาน
  • ในการทดลองกับรีโพซิทอรีขนาดเล็ก GitHub ดาวน์โหลด 291 คำขอ พร้อมข้อมูลตอบกลับแบบย่อขนาด 15MiB และเมื่อขยายแล้ว 544,564 บรรทัด ซึ่งต่างจาก Codeberg ที่มีเพียง 11 คำขออย่างมาก
  • ในการวัดฝั่งฟรอนต์เอนด์ GitHub ใช้ฮีปขณะปกติราว 69MiB และหน้าของ pull request ใน rust-lang ใช้ 148MiB จนถูกมองว่าสิ้นเปลืองเกินควรสำหรับหน้าที่เน้นข้อความ
  • บทสรุปคือความสิ้นเปลืองของ GitHub ไม่ใช่แค่การเสื่อมคุณภาพของผลิตภัณฑ์ตามปกติ แต่เป็นความล้มเหลวของซอฟต์แวร์ที่ให้ความสำคัญกับ ฟีเจอร์ AI และลำดับความสำคัญที่ยึดนักลงทุนเป็นศูนย์กลาง มากกว่าการแก้ปัญหาให้ผู้ใช้

ความน่าเชื่อถือและลำดับความสำคัญของ GitHub

  • GitHub ถูกใช้งานราวกับเป็นแกนหลักของโครงสร้างพื้นฐานการพัฒนาซอฟต์แวร์ แต่กลับถูกตั้งคำถามเรื่อง ความน่าเชื่อถือพื้นฐาน จากปัญหา downtime ประสิทธิภาพตก และการเข้ากันได้กับเบราว์เซอร์
  • บันทึก GitHub Status แสดงให้เห็นว่ามีอินซิเดนต์หลายสิบครั้งต่อเดือน และเมื่อดูจาก หน้าสถานะอย่างเป็นทางการ กับเกณฑ์ SLA ก็มีสถานการณ์ที่อาจถือว่าเข้าข่ายละเมิดได้
  • มีเสียงวิจารณ์ว่ามักพังบ่อยใน Firefox และ Safari ขณะที่หน้าความคิดเห็นและรีวิวของ pull request ก็ช้า และยังมีการใช้ RAM กับการพุ่งขึ้นของฮีปมากเกินไป
  • GitHub Actions ถูกมองว่าช้า เอกสารไม่เพียงพอ และหน้าจอ log ก็ถูกยกเป็นตัวอย่างว่าก่อให้เกิด memory leak และเบราว์เซอร์แครชมาหลายปี
  • แม้แต่พฤติกรรมแคชของแอ็กชันพื้นฐานอย่าง setup-go ก็ถูกมองว่าไม่มีการทำ invalidation หรือเรียบง่ายเกินไป
  • มีเว็บไซต์อย่าง githubstars.com ที่โฆษณาขายดาวอย่างเปิดเผย และยังมีการอ้างอิงข้อความ “fake stars are highly related to malicious activities” จาก งานวิจัยของ Carnegie Mellon
  • สิ่งที่ GitHub ควรมุ่งไปคือ ระบบกระจายศูนย์ที่มีสมรรถนะสูง ความพร้อมใช้งานสูง และรองรับปริมาณงานสูง แต่ผลิตภัณฑ์จริงกลับถูกมองว่าให้ความสำคัญกับฟีเจอร์ AI และ workflow แบบ agent มากกว่าความน่าเชื่อถือพื้นฐาน

ภาระงานแบบ “Agentic” และความรับผิดชอบของ Microsoft

  • GitHub ระบุใน ‘an update on github availability’ ว่าหลังครึ่งหลังของเดือนธันวาคม 2025 เป็นต้นมา agentic development workflows เร่งตัวขึ้นอย่างรวดเร็ว และการสร้างรีโพซิทอรี กิจกรรม pull request การใช้ API ระบบอัตโนมัติ และเวิร์กโหลดของรีโพซิทอรีขนาดใหญ่ก็เพิ่มขึ้นอย่างมาก
  • คำอธิบายนี้ปฏิบัติต่อภาระงานที่เพิ่มขึ้นราวกับเป็นปรากฏการณ์จากภายนอก แต่ก็นำไปสู่คำวิจารณ์ว่า GitHub และ Microsoft ซึ่งเป็นบริษัทแม่ ต่างเป็นฝ่ายยัด AI และ “agents” เข้าไปในหลายผลิตภัณฑ์เพื่อผลักดันการใช้งานโดยตรง
    • แถบด้านบนของเกือบทุกหน้าบน GitHub มีปุ่ม AI อยู่ 3 ปุ่ม และในนั้น 2 ปุ่มมีไว้เพื่อเริ่ม agent โดยเฉพาะ ขณะที่หลายหน้ามีถึง 4 ปุ่ม
    • บริเวณด้านขวาบนของหน้า landing ของรีโพซิทอรีทั่วไป มีวิธีเรียกใช้ Copilot อยู่ 4 แบบ
    • มีการยก ลิงก์วิจารณ์ ที่ชี้ว่า GitHub อุดหนุนต้นทุนการใช้เครื่องมือมาหลายปีเพื่อเร่งการยอมรับ ซึ่งไม่ต่างจากการช่วยออกค่าใช้จ่ายให้การโจมตีแบบ distributed denial of service แก่ตัวเอง
  • Microsoft อธิบายว่า pull request หนึ่งรายการอาจไปแตะทั้ง Git repository การตรวจสอบความสามารถในการ merge, branch protection, GitHub Actions, การค้นหา, การแจ้งเตือน, สิทธิ์, webhooks, APIs, งานเบื้องหลัง, แคช และฐานข้อมูล
  • ในระดับขนาดใหญ่ ความไม่มีประสิทธิภาพเพียงเล็กน้อยก็อาจนำไปสู่คิวสะสม cache miss ภาระบน DB ความล่าช้าของอินเด็กซ์ และการขยายตัวของทราฟฟิกจากการ retry แต่ความไม่มีประสิทธิภาพของ GitHub ถูกมองว่าไม่ใช่ระดับ “เล็กน้อย” หากเป็นระดับ มหาศาลและท่วมท้น
  • แม้ Microsoft จะระบุว่า “availability first, then capacity, then new features” แต่ใน GitHub public changelog ภายใน 30 วันหลังอัปเดตดังกล่าว คำว่า “copilot” ปรากฏใน patch note 59 ครั้ง “agent” 8 ครั้ง ขณะที่ “performance” และ “reliability” ปรากฏ 0 ครั้ง
    • ในตัวกรอง changelog มีหมวด copilot แยกต่างหาก แต่ไม่มีหมวด performance หรือ reliability
    • ยังมีคำวิจารณ์ว่า Visual Studio Code ก็ผสานรวมกับ GitHub และฟีเจอร์ “agentic” โดยตรงเช่นกัน และแม้ฟังก์ชันพื้นฐานอย่าง terminal ในตัวจะเสื่อมลง ก็ยังคงมีการเพิ่มฟีเจอร์ agent เข้ามาอีก
  • ช่วงที่ Microsoft ระบุว่าจะลด “unnecessary work” ปรับปรุงการแคช แยกบริการสำคัญ กำจัด single point of failure ย้ายเส้นทางที่ไวต่อประสิทธิภาพ ลด coupling ที่ซ่อนอยู่ จำกัด blast radius และทำ graceful degradation ถูกตีความว่าเป็น การยอมรับว่าการออกแบบระบบมีปัญหา

ทำไมฟรอนต์เอนด์จึงบ่งชี้ถึงปัญหาที่แบ็กเอนด์

  • รากของปัญหาความน่าเชื่อถือของ GitHub อยู่ที่แบ็กเอนด์และฐานข้อมูล แต่คนภายนอกมองไม่เห็น จึงทำได้เพียงสังเกต โค้ดฝั่งฟรอนต์เอนด์ อย่าง HTML, JavaScript และ CSS ที่ถูกดาวน์โหลดมาในทุกครั้ง
  • เปรียบเหมือนถ้าเห็นหนูในโซนรับประทานอาหารของร้านพิซซ่า ก็ยากจะเชื่อได้ว่าครัวจะสะอาดไร้ที่ติ ความเสื่อมโทรมที่เห็นได้ชัดในฟรอนต์เอนด์ของ GitHub จึงชี้ให้เห็นถึงปัญหาแบ็กเอนด์ แม้จะไม่อาจพิสูจน์ได้โดยตรง
  • หน้า landing ของรีโพซิทอรีใน GitHub, GitLab และ Codeberg ประกอบด้วยรายการลิงก์ องค์ประกอบ UX เล็กน้อย ปุ่ม แท็บ และช่องค้นหา โดยแทบไม่มีองค์ประกอบที่กินทรัพยากรสูงอย่างสื่อโต้ตอบหรือรูปภาพ
  • หน้าแบบนี้ควรทำงานได้อย่างเบา ๆ บนคอมพิวเตอร์หรือโทรศัพท์เกือบทุกเครื่อง แม้จะอยู่บนการเชื่อมต่ออินเทอร์เน็ตที่ไม่ดีนัก และมีการยกว่าก่อนหน้านี้ GitHub ก็เคยทำได้จริงแม้บน iPhone 4 และเครือข่าย 3G
  • หากฟังก์ชันเหมือนกัน โค้ดที่ดีที่สุดนิยามได้ว่าเป็นโค้ดที่ใช้แบนด์วิดท์เครือข่าย เวลา CPU และ RAM น้อยที่สุด พร้อมมีบั๊กน้อยที่สุด
  • แม้จะไม่สามารถรู้จำนวนบั๊กฝั่งฟรอนต์เอนด์ได้โดยตรง แต่งานศึกษาทางประวัติศาสตร์ชี้ว่าจำนวนบั๊กมักแปรผันตามจำนวนบรรทัดของโค้ด
    • Steve McConnel, Code Complete, 2nd Ed (2004) ถูกอ้างว่าค่าเฉลี่ยข้อผิดพลาดของซอฟต์แวร์ที่ส่งมอบในอุตสาหกรรมอยู่ที่ 1–25 ข้อต่อโค้ด 1,000 บรรทัด
    • มีการอ้างว่า Microsoft Applications Division พบข้อบกพร่อง 10–20 ข้อต่อโค้ด 1,000 บรรทัดระหว่างการทดสอบภายใน และ 0.5 ข้อต่อ 1,000 บรรทัดในผลิตภัณฑ์ที่วางจำหน่ายแล้ว

การออกแบบการทดลองและวิธีเก็บข้อมูล

  • เพื่อลดตัวแปรกวน จึงจำกัดความเร็วอินเทอร์เน็ตไว้ที่การเชื่อมต่อแบบ “fast 3G”
    • เป็นการตั้งค่าเพื่อลดผลกระทบจากความผันผวนของสภาพเครือข่าย และจำลองประสบการณ์ของลูกค้า GitHub ในสภาพที่ไม่อุดมคตินัก เช่น พื้นที่ชนบท
  • ทั้งสามบริการใช้รีโพซิทอรีขนาดเล็กชุดเดียวกันคือ ghsucks
    • มี branch เดียวคือ master
    • มีไฟล์เดียวคือ README.md
    • ไม่มีองค์ประกอบเสริมอย่าง issues หรือ tags
  • ใช้เบราว์เซอร์เดียวกันและคอมพิวเตอร์เครื่องเดียวกัน
    • Firefox
    • Apple Macbook Pro M5 Max
    • RAM 48GiB
  • สำรวจ 4 หน้าจากแต่ละบริการ
    • หน้า “landing”: โครงหน้าสำหรับโค้ด
    • หน้า “pull requests” หรือ “merge requests”
    • หน้า “issues”
    • หน้า “settings”
  • เก็บ HTTP Archive (HAR) ภายใต้สถานะแคชสะอาดเพื่อวิเคราะห์คำขอเครือข่าย และหลังโหลดเสร็จจึงเก็บ heap snapshot เพื่อประเมินการใช้ RAM ในสภาวะคงตัว
  • สำหรับการวิเคราะห์ HAR ใช้ anhar ที่เขียนขึ้นเอง สำหรับการวิเคราะห์ที่รองรับการบีบอัดใช้ testcompress และใช้ pagespeed.web.dev เพื่อตรวจสอบไขว้

การใช้ฮีปและการสิ้นเปลืองหน่วยความจำ

  • การวัดการใช้ฮีปของหน้ารีโพซิทอรีเริ่มต้นพบว่า GitHub ใช้ 69MiB, GitLab 68MiB, Codeberg 14MiB และ eblog.fly.dev 1.3MiB
  • การเรนเดอร์หน้า issue แรกของ https://github.com/rust-lang/rust/pulls ใช้ RAM 148MiB
  • 148MiB เป็นหน่วยความจำที่มากกว่า iPhone รุ่นแรก และถูกประเมินว่าเป็นการสิ้นเปลืองที่ รุนแรงมาก สำหรับหน้าแบบเน้นข้อความที่มีเพียงลิงก์ไม่กี่รายการ
  • หน่วยความจำของอุปกรณ์ที่ยกมาเปรียบเทียบ ได้แก่ Apple iphone 1 128MiB, iphone 4 512MiB, Sony playstation 2 32MiB และ Nintendo wii 88MiB

เปรียบเทียบปริมาณคำขอและขนาดการตอบสนอง

  • anhar เป็นโปรแกรม Go ที่พาร์ส HAR JSON, จัดฟอร์แมต HTML·CSS·JavaScript ของการตอบสนองโดยอัตโนมัติด้วย deno fmt แล้วคำนวณขนาดคำขอ·การตอบสนอง, ผลรวมตาม MIME, เวลาโหลด และจำนวนบรรทัดของการตอบสนอง
  • ตัวชี้วัดหลักคือขนาดคำขอ, ขนาดการตอบสนองแบบย่อที่รับมาจริง, ขนาดการตอบสนองหลังขยายเมื่อใช้ deno fmt และจำนวนบรรทัด, เวลาโหลด HTML พื้นฐานอย่าง Content-Load และเวลาโหลดคอนเทนต์ทั้งหมดอย่าง Load
  • หน้ารีโพซิทอรี Codeberg วัดได้รวม 11 คำขอ, คำขอ 9KiB, การตอบสนอง 1MiB, การตอบสนองหลังขยาย 1MiB, หลังขยาย 3,480 บรรทัด, Content-Load 2.934s, Load 3.172s
  • หน้ารีโพซิทอรี GitHub วัดได้ 291 คำขอ, คำขอ 178KiB, การตอบสนองแบบย่อ 15MiB, การตอบสนองหลังขยาย 22MiB, หลังขยาย 544,564 บรรทัด, Content-Load 843ms, Load 21.330s
    • application/javascript: 214 คำขอ, การตอบสนอง 12MiB, การตอบสนองหลังขยาย 19MiB, หลังขยาย 481,849 บรรทัด
    • text/css: 42 คำขอ, การตอบสนอง 2MiB, หลังขยาย 60,016 บรรทัด
    • GitHub pulls: 266 คำขอ, แบบย่อ 14MiB, หลังขยาย 20MiB, หลังขยาย 487,922 บรรทัด, Content-Load 592ms, Load 6.754s
    • GitHub settings: 255 คำขอ, แบบย่อ 14MiB, หลังขยาย 20MiB, หลังขยาย 486,067 บรรทัด, Content-Load 778ms, Load 6.963s
  • GitLab มีขนาดเล็กกว่า GitHub แต่ก็ยังหนักอยู่
    • รีโพซิทอรี GitLab: 78 คำขอ, การตอบสนอง 8MiB, หลังขยาย 101,682 บรรทัด, Content-Load 6.880s, Load 12.941s
    • GitLab merge_requests: 65 คำขอ, การตอบสนอง 7MiB, หลังขยาย 90,567 บรรทัด, Content-Load 6.947s, Load 12.096s
    • GitLab edit: 117 คำขอ, การตอบสนอง 7MiB, หลังขยาย 71,916 บรรทัด, Content-Load 6.964s, Load 13.302s
  • GitHub ดึงโค้ดและข้อมูล ราว 540K บรรทัด แม้แต่ตอนแสดงรีโพซิทอรีว่าง โดยมีการเปรียบเทียบว่านี่ยังมากกว่า DOOM 35K บรรทัด, Windows Quake 120K บรรทัด, MS-DOS 4.0 332K บรรทัด และ Zig toolchain 460K บรรทัด
  • โครงสร้างที่แต่ละหน้าดึงไฟล์ CSS 40 ไฟล์และ JavaScript อีกหลายร้อยไฟล์ ถูกประเมินว่าเป็นปัญหา
  • การแบ่งชังก์ของ Webpack ในทางทฤษฎีอาจช่วยแยกฟังก์ชันหลักกับฟังก์ชันเสริม และเป็นประโยชน์ต่อแคชกับ CDN แต่ในที่นี้ถูกตีความว่าให้ผลเป็นการทำให้โหลดช้าลง เพราะแต่ละไฟล์ต้องใช้คำขอ HTTP แยกกัน
  • การต้องรอ 22 วินาที เพื่อดูหน้าเปล่านั้นยอมรับได้ยาก และยังถูกประเมินว่าต่อให้ใช้บรอดแบนด์ระดับมากกว่า 1GiB/s กับโปรเซสเซอร์คอนซูเมอร์ประสิทธิภาพสูง ก็ยังต้องใช้เวลามากกว่า 1 วินาทีกว่าที่รีโพซิทอรีจะเริ่มใช้งานได้ในระดับหนึ่ง

เปรียบเทียบการรองรับการบีบอัด

  • การบีบอัดถูกเสนอว่าเป็นวิธีที่มีประโยชน์ในการลดภาระของไคลเอนต์·เซิร์ฟเวอร์·และเส้นทางกลาง
  • gzip เป็นมาตรฐานการบีบอัดที่ผ่านการพิสูจน์แล้วและทุกเว็บไซต์ควรรองรับ ส่วน zstd มีคุณลักษณะด้านประสิทธิภาพที่ดี แต่เป็นแนวทางที่ใหม่กว่า จึงถูกมองว่าอยู่ในระดับ “มีก็ดี”
  • testcompress เป็นโปรแกรม Go ที่ทดสอบว่า URL รองรับการบีบอัด gzip และ zstd หรือไม่ และหากไม่รองรับ ก็จะบีบอัดเนื้อหาการตอบสนองโดยตรงเพื่อแสดงปริมาณที่อาจประหยัดได้
  • eblog.fly.dev/startingsystems3.html: การเข้ารหัสที่รองรับ zstd gzip, ต้นฉบับ 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
  • github.com/ef0xa/ghsucks: การเข้ารหัสที่รองรับ gzip, ต้นฉบับ 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks: การเข้ารหัสที่รองรับ gzip, ต้นฉบับ 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks: การเข้ารหัสที่รองรับ n/a, ต้นฉบับ 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

ผลลัพธ์ PageSpeed บนมือถือ

  • ในการวัดบนมือถือของ pagespeed.web.dev Codeberg ได้ PASS ด้วย First Contentful Paint 1.2s, Largest Contentful Paint 1.3s และ Interaction to Next Paint 86ms
  • eblog.fly.dev ได้ PASS ด้วย First Contentful Paint 1.1s, Largest Contentful Paint 1s และ Interaction to Next Paint N/A
  • GitHub ได้ FAIL ด้วย First Contentful Paint 1.8s, Largest Contentful Paint 2.1s และ Interaction to Next Paint 242ms
  • GitLab ได้ FAIL ด้วย First Contentful Paint 2.1s, Largest Contentful Paint 2.4s และ Interaction to Next Paint 243ms

การประเมินแยกตามบริการ

  • GitHub

    • นำเข้าไฟล์ประมาณ 300 ไฟล์, โค้ดและข้อมูลราว 550,000 บรรทัด และประเมินว่ามีบั๊กประมาณ 550 จุด
    • สรุปว่า Content-Load อยู่ที่ราว 800ms, Load ทั้งหมดราว 7s และ heap ในสถานะคงที่ราว 69MiB
    • รองรับ gzip แต่ไม่รองรับ zstd
    • ได้คะแนน F โดยถูกประเมินว่าโค้ดมีขนาดใหญ่เทอะทะมาก
    • มีข้อชี้ว่า GitHub ดึงทุกธีมมาทุกหน้าทั้งที่ผู้ใช้จะใช้หรือไม่ใช้ก็ตาม
    • เนื่องจาก pagespeed.web.dev ระบุว่า JavaScript และ CSS ขนาด 528KiB ไม่ได้ถูกใช้งานเลย จึงมองว่าสามารถเริ่มลดจากส่วนนี้ได้
    • มีข้อเสนอว่าหากยังต้องอยู่บน GitHub ก็ควรมองว่ากำลังละเมิด SLA ของ GitHub เอง และให้ส่ง support ticket เพื่อขอเงินคืน

  • GitLab

    • Content-Load อยู่ที่ราว 7s, Load อยู่ที่ราว 13s และมีมากกว่า 70 ไฟล์ รวม 7MiB, ราว 10,000 บรรทัด
    • heap ในสถานะคงที่ราว 68MiB และรองรับ gzip แต่ไม่รองรับ zstd
    • ได้คะแนน D+ โดยถูกประเมินว่าแม้จะสิ้นเปลืองน้อยกว่า GitHub แต่ก็ดึงทรัพยากรมากเกินไปและใช้งานได้ไม่คุ้ม
    • ดึง JavaScript และ CSS มาเกิน 1MiB แต่มีส่วนที่ไม่ได้ถูกใช้งานจริงเลย และในโค้ดที่ถูกใช้ก็ยังมี chunk ขนาด 3MiB ที่ใช้เวลา parse อย่างเดียว 255ms
    • มองว่า landing page ไม่จำเป็นต้องใช้ CSS 55,000 บรรทัด และทั้ง CSS กับ JavaScript น่าจะลดลงได้เหลือเพียง 1 ใน 10 ของปัจจุบัน

  • Codeberg/Forgejo

    • Content-Load อยู่ที่ 2.9s, Load อยู่ที่ 3.1s และดึงข้อมูล 11 ไฟล์รวม 1MiB, ราว 1,100 บรรทัด
    • heap ในสถานะคงที่ราว 14MiB และไม่รองรับทั้ง gzip และ zstd
    • ได้คะแนน C+ โดยถูกประเมินว่าพื้นฐานดี แต่ยังขาดความใส่ใจในรายละเอียดและประสบการณ์
    • การไม่ทำ HTML minify เป็นปัญหาเล็ก แต่ การไม่รองรับการบีบอัด ถูกมองว่าเป็นข้อบกพร่องใหญ่
    • JavaScript และ CSS ส่วนใหญ่ไม่จำเป็นต่อการเรนเดอร์หน้า แต่ปัญหาคือถูกโหลดในลักษณะที่ขัดขวางการเรนเดอร์
    • มีข้อเสนอให้รวม payload ของ JavaScript และ CSS เพื่อลดจำนวน request และควรรองรับการบีบอัด gzip และ zstd สำหรับ HTTP payload รวมถึง HTML
    • ข้อดีคือเป็นซอฟต์แวร์เสรี จึงย้ายไปยังอินสแตนซ์อื่นหรือโฮสต์เองได้

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html วัดได้ว่า Content-Load 76ms, Load 1.1s, 5 ไฟล์ 766KiB, ราว 3,800 บรรทัด
    • ไฟล์ HTML เดี่ยวมีขนาด 576KiB และเมื่อบีบอัดด้วย zstd จะเหลือราว 70KiB
    • heap ในสถานะคงที่ราว 11MiB และรองรับทั้ง zstd และ gzip
    • ได้คะแนน A- โดยถูกประเมินว่าโดยรวมดี แต่ HTML ยังใหญ่และซ้ำซ้อนแม้จะคำนึงถึงการบีบอัดแล้ว และหน้าที่ควรจบได้ใน request เดียวกลับต้องใช้ 5 request

ไม่ใช่แค่ผลิตภัณฑ์เสื่อมลงอย่างเดียว แต่เป็นปัญหาเรื่องต้นทุน

  • “enshittification” ถูกสรุปว่าเป็นกระบวนการที่ผลิตภัณฑ์เริ่มต้นด้วยการเอื้อประโยชน์ต่อผู้ใช้และลูกค้าธุรกิจ จากนั้นเปลี่ยนไปในทางที่เสียต่อผู้ใช้ แล้วต่อมาก็เสียต่อลูกค้าธุรกิจด้วย ขณะที่กลับเป็นประโยชน์ต่อผู้ให้บริการ
  • Microsoft และ GitHub อาจไม่แยกขาดจาก Embrace, Extend, Extinguish แต่เห็นว่าปัญหาในที่นี้ต่างออกไป เพราะมันสร้างต้นทุนไม่ใช่แค่กับผู้ใช้และลูกค้าธุรกิจ แต่รวมถึง Microsoft เองด้วย
  • codebase ที่พองตัวขึ้นเพิ่มต้นทุนเซิร์ฟเวอร์และแบนด์วิดท์โดยตรง และยังทำให้ต้องใช้เวลาเชิงวิศวกรรมทางอ้อมในการดูแล codebase ที่ไม่เสถียรและเทอะทะ
  • หากสมมติว่า GitHub มีวิศวกรประมาณ 800 คน และแต่ละคนทำงานสัปดาห์ละ 40 ชั่วโมง ปีละ 48 สัปดาห์ ก็จะเท่ากับ 1,536,000 engineer-hour ต่อปี
  • มองว่าปัญหาฝั่งฟรอนต์เอนด์ส่วนใหญ่ แค่วิศวกรที่มีความสามารถทำตามคำแนะนำของ pagespeed ก็สามารถแก้หรือบรรเทาได้ภายในหนึ่งสัปดาห์
  • เหตุผลที่การปรับปรุงระดับล่างซึ่งช่วยลดต้นทุนได้ยังถูกปล่อยทิ้งไว้ ถูกตีความได้ว่าเป็นเพราะความไม่ใส่ใจ ความไร้ความสามารถอย่างรุนแรง หรือถูกขัดขวางโดยภาวะผู้นำที่ยึด AI และนักลงทุนเป็นศูนย์กลาง
  • ซอฟต์แวร์ถูกอธิบายว่าเป็นเครื่องมือที่ทรงพลังและงดงาม เพราะเมื่อเขียนได้อย่างถูกต้องหนึ่งครั้งแล้ว ก็สามารถคัดลอกได้อย่างสมบูรณ์ ตลอดไป และไม่มีต้นทุน เพื่อให้ทุกคนใช้งานได้
  • บทสรุปคือความสิ้นเปลืองและความไร้ความสามารถของ GitHub และบริการลักษณะเดียวกัน ไม่ใช่แค่ผลิตภัณฑ์ที่แย่ แต่เป็น อาชญากรรมต่อซอฟต์แวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 22 시간 전
ความคิดเห็นจาก Lobste.rs

  • อยากให้รวม Trac และ Sourcehut ไว้ในการเปรียบเทียบนี้ด้วย

  • ปุ่ม AI agent 4 ปุ่มมันก็ตลกดี และตัวเลขเชิงเปรียบเทียบในบทความก็น่าสนใจ แต่ถึงอย่างนั้นก็ไม่ได้หมายความว่าจะปกป้อง GitHub เลย เพียงแต่รายละเอียดบางส่วนในบทความขาดบริบทไปหน่อย เลยดูไม่เพียงพอที่จะรองรับข้อโต้แย้งของผู้เขียน
    การใช้หน่วยความจำว่างอาจเป็นสัญญาณว่า GitHub ทำอะไรได้มากกว่า Codeberg แต่ก็ยากจะสรุปอะไรอย่างมีนัยสำคัญจากการเอาปริมาณ RAM แบบสัมบูรณ์บน คอมพิวเตอร์ RAM 48GB ไปเทียบกับคอมพิวเตอร์นำวิถี Apollo
    การจัดฟอร์แมต JavaScript bundle ที่ถูก minify แล้วเพื่อประเมินจำนวนบรรทัดโค้ด แล้วเอาไปเทียบกับจำนวนบรรทัดของโปรเจ็กต์ Zig ที่ไม่รวม dependency ก็เป็นการเทียบคนละเรื่องกัน เหมือนเอาแอปเปิลไปเทียบส้ม ถ้าจะให้เทียบกันจริงก็ต้องลอง decompile ไฟล์รันได้ของ Zig ดูว่าจะได้กี่บรรทัด
    ผมก็ไม่เข้าใจคำแนะนำที่ว่า Codeberg ควร “รวม JavaScript และ CSS payload เข้าด้วยกันเพื่อลดจำนวน request” เหมือนกัน พอเห็นพูดถึง “overhead เพิ่มเติม” ของ HTTP request ก็ชวนสงสัยว่าผู้เขียนรู้จัก HTTP/2 หรือเปล่า
    ยังมีเรื่อง performance ของเว็บเพจที่อยากพูดอีกเยอะ แต่คงแยกไปเขียนต่างหาก และถ้าอยากได้มุมมองที่ดีกว่าในประเด็นคล้ายกัน แนะนำให้อ่านบทความเก่าเรื่อง web bloat ของ Danluu ปี 2017 อีกรอบ: https://danluu.com/web-bloat

  • ถ้าผู้เขียนกำลังอ่านอยู่ อยากให้ลองดูประเด็นถกเถียงระหว่าง Casey Muratori กับ Uncle Bob เพราะฝ่ายแรกเจอปัญหาด้านประสิทธิภาพที่น่าสนใจมาก
    “ผมอดไม่ได้เลยไปเปิด Chrome performance capture ดู แล้วก็รู้ว่าใครเป็นตัวการ :) มันคือ ‘emoji picker’!”
    “ผมดูโค้ดแบบผ่านๆ แต่ดูเหมือนปัญหาคือทุกครั้งที่พิมพ์ตัวอักษร ‘emoji picker’ จะไล่ย้อนกลับไปตรวจว่าที่เพิ่งพิมพ์ไปเป็นอีโมจิหรือเปล่า”
    โอ๊ย. แต่ในกรณีนี้ตัวการอาจไม่ใช่โค้ดฝั่งฟรอนต์เอนด์ของ GitHub แต่อาจเป็น เบราว์เซอร์สาย Chromium ก็ได้

  • คำพูดที่ว่า “Codeberg เป็นผลิตภัณฑ์ที่พึ่งพาเงินบริจาคอิสระและแรงงานอาสาสมัคร” นั้นไม่ตรงนัก
    Codeberg พึ่งพา สมาชิก ทั้งในแง่ค่าสมาชิกและในเชิงนโยบายด้วย และแม้ตอนนี้ค่าสมาชิกอย่างเดียวจะยังไม่พอจ้างพนักงานประจำเต็มเวลา จึงยังต้องพึ่งอาสาสมัครอย่างมาก แต่เท่าที่เข้าใจพวกเขาก็มีผู้รับจ้างอยู่ด้วย
    ผมไม่ได้ตาม Codeberg ลึกมากนัก (ค่อนข้างชอบฝั่ง sourcehut มากกว่า) แต่ความเป็นสหกรณ์ก็เป็นหนึ่งในหัวใจสำคัญของคุณค่าที่เสนอไว้ และพวกเขาก็พยายามเปิดเผยค่าใช้จ่ายอย่างโปร่งใสด้วย ตัวอย่างเช่น: https://blog.codeberg.org/codebergs-budget-of-2026.html
    ถ้าคุณใช้ Codeberg อยู่ ก็น่าจะลองพิจารณาสมัครสมาชิกตอนนี้: https://join.codeberg.org/

  • ผมเกลียด GitHub มากจริงๆ ปัญหาของผมไม่ใช่เรื่อง uptime แต่เป็นความช้าแบบเหลือเชื่อและกินหน่วยความจำมาก “diff ขนาดนี้จะไม่แสดงโดยค่าเริ่มต้น” นี่พูดจริงเหรอ
    มันยังพังกับ workflow การพัฒนาที่สมเหตุสมผลด้วย ถ้า rebase PR ความเห็นรีวิวกับคอมเมนต์จะหายไป แล้วถ้า squash commit ความเห็นรีวิวกับคอมเมนต์ก็หายไปอีก
    ถึงจะมีลิงก์ไปยังคอมเมนต์เฉพาะ แต่ถ้า commit นั้นหายไป คอมเมนต์ก็หายตามไปด้วย \o/
    ถ้ามีการแก้บั๊กก็ให้เปิด PR แต่ถึงบั๊กนั้นจะถูกแก้ไปแล้วด้วยการเปลี่ยนแปลงอื่น PR กับบั๊กก็ยังอยู่คนละระดับ ทำให้ PR ที่ตายแล้วค้างอยู่ในคิวรีวิวตลอดกาล
    ถ้าอยากรู้ว่า commit นี้แก้บั๊กอะไร GitHub ก็จะพาไปดูแต่ประวัติ PR เหมือนบอกว่าอย่าดูบั๊ก ให้ดู PR แทน และถ้าอยากรู้เรื่องบั๊กก็ต้องไปค้นเอง

    • แนวคิดเรื่อง “pull request” เองก็เหมือน git ตรงที่มาจาก การพัฒนา Linux kernel เป็น workflow ที่ขอให้ maintainer ของเคอร์เนลดึง patch เข้า mainline
      GitHub ทำให้ workflow นี้สะดวกขึ้นด้วยปุ่ม “fork” และทำให้ดู “social” มากขึ้นด้วยชื่อผู้ใช้แบบศูนย์กลาง แล้วก็ผูก issue tracker กับ wiki เข้าไปจนยึดครองโลกได้ ในเชิงธุรกิจก็ต้องยอมรับว่าเป็นอัจฉริยะ
      แต่ workflow ทั้งหมดก็ยังถูกออกแบบมาสำหรับการพัฒนาโอเพนซอร์สที่คนซึ่งอยู่กันคนละที่ส่งคำขอให้ “pull” patch อยู่ดี
      ผมไม่เข้าใจว่าทำไมทีมพัฒนาที่ทำงานใกล้ชิดกัน ซึ่งกลไกจริงคือ “คุยกันเรื่อง branch แล้วอนุมัติการ merge” ถึงยังต้องใช้ “pull request” ด้วย มันจะ pull มาจากอะไร ในเมื่ออยู่ repository เดียวกันและ push การเปลี่ยนแปลงเข้าไปแล้ว
      ต่อให้ไม่นับเรื่องคำศัพท์ การไม่มี stacked changes, คอมเมนต์ที่คงอยู่ถาวร, และ diff ของชุดการเปลี่ยนแปลง ก็ยังไร้เหตุผลอยู่ดี
      ขอโทษที่มาบ่นเรื่อง GitHub แบบเดิมๆ อีกแล้ว มีทางเลือกที่ดีกว่านี้ไหมนะ? ถึงสุดท้ายจะบังคับให้ใครใช้ไม่ได้ก็เถอะ…

  • ผมเคยเห็นคนตอบสนองกับกราฟที่ GitHub เผยแพร่ว่า “กราฟที่ไม่มีป้ายแกนหรือตัวเลขของแต่ละจุดข้อมูลควรถูกตั้งข้อสงสัยเสมอ” อยู่หลายครั้ง
    ในกราฟมีการแสดงค่าสูงสุดไว้ ดังนั้นด้วยสายตาก็น่าจะเดาได้ว่าค่ากลางของแกน y น่าจะอยู่ราวๆ 45M, 0.7B และ 10M ตามลำดับ เว้นแต่ว่าจะแอบใช้สเกลลอการิทึมและภาระงานไม่ได้เพิ่มขึ้น 100000 เท่า
    สำหรับกรณีนี้ ผมคงไม่เรียกกราฟแย่ๆ ว่า “น่าสงสัย” แค่คิดว่า สื่อสารได้ไม่ดี มากกว่า โดยส่วนตัวผมชอบเอาต์พุต ggplot แบบดิบๆ มากกว่าเสมอ
    โดยรวมผมเห็นด้วยกับอารมณ์ของบทความ แต่ช่วงที่พูดถึงคำอุปมาอ้วนๆ กับตารางเยอะๆ ทำให้ตามยากนิดหน่อย อย่างไรก็ตาม ถ้าผมต้องลิสต์ข้อบกพร่องทั้งหมดของ GitHub เอง ก็คงเริ่มเพ้อฝันถึงการขี่ม้าอ้วนๆ หายลับไปในแสงอาทิตย์ยามเย็นเหมือนกัน
    ผมเองก็เคยเริ่มทำรายการคล้ายๆ กัน แต่พอปัญหา UX/performance แตะราว 12 ข้อก็เลิกแล้ว ชอบการวิเคราะห์อย่างละเอียดของบทความนี้ และหวังว่าทีม GitHub จะหยิบไปชำแหละจริงจัง
    อย่างที่เคยพูดก่อนหน้านี้ Microsoft ควรจัดสรร วิศวกรด้านประสิทธิภาพ บางส่วนให้ GitHub จนกว่าตัวชี้วัดด้านประสิทธิภาพจะถูกใส่เข้าไปใน KPI อย่างจริงจัง ความอืดบวมนี้ก็จะยังดำเนินต่อไป และแพลตฟอร์มอื่นก็จะดูน่าสนใจกว่า หวังว่าถ้ามี CEO คนต่อไปของ GitHub เขาจะให้เรื่องนี้เป็นลำดับความสำคัญ

    • คุณกำลังสมมติว่าแกน y ของกราฟเริ่มจาก 0 แต่ใน กราฟสไตล์ธุรกิจ แบบนี้ หลายครั้งมันไม่ได้เป็นแบบนั้น
      มักจะเป็นแนวที่อ้างว่า “เติบโตมหาศาล” ทั้งที่เส้นกราฟพาดทแยงเต็มพื้นที่รูป แต่แกน y อาจวิ่งแค่จาก 100 ถึง 101 เท่านั้น

  • เห็นด้วยกับที่ว่า “ล็อกของ GitHub Actions มี memory leak จนทำให้เบราว์เซอร์ของฉันพังมาหลายปี และจนถึงตอนนี้ก็ยังไม่มีวิธี pipe stdout ออกไปที่อื่นแบบตรงๆ ได้เลย”
    น่าเสียดายที่ Forgejo ก็รับมรดกปัญหานี้มาด้วย บางครั้งผมได้รับการแจ้งเตือนว่า build ล้มเหลวแล้วอยากรีบเปิดดูจากมือถือ แต่หลายกรณีเบราว์เซอร์บนมือถือกลับโหลด output ไม่ขึ้นเลย

  • ตอนกดเข้ามาอ่านบทความนี้ ผมนึกว่าจะเป็นแค่การบ่นเรื่อง uptime ของ GitHub อีกชิ้นแน่ๆ แต่กลับกลายเป็นบทความที่ประเมินปัญหาปัจจุบันของ GitHub, GitLab และ Codeberg อย่างใจเย็น มีเหตุผล และยังเสนอทางแก้ไว้ด้วย เลยประทับใจแบบเหนือความคาดหมาย
    อยากให้เพิ่ม Tangled เข้าไปในการเปรียบเทียบด้วย
    ผู้เขียนน่าจะเขียน CSS เพิ่มหน่อยให้เว็บอ่านบนมือถือได้ ผมต้องใช้โหมดอ่านของเบราว์เซอร์
    ส่วนเดียวที่ผมไม่เห็นด้วยคือข้ออ้างที่ว่าเว็บไหนๆ ก็ไม่ควรโหลดไฟล์ JavaScript/CSS มากกว่าหนึ่งไฟล์
    ถ้า JavaScript 550,000 บรรทัดนั้นอยู่ในไฟล์เดียวหมด การ parse และ execution คงใช้เวลานานกว่านี้มาก CSS อาจจะ bundle ได้ แต่ตัวอย่างเช่นรูปแบบที่มี common chunk หนึ่งก้อนกับ route-specific chunk อีกก้อนก็อาจมีประโยชน์ แนวทางแบบนี้หรือใกล้เคียงกันน่าจะถูกใช้อย่างแพร่หลาย

  • หน้านี้อ่านไม่ไหวจริงๆ
    แล้วถ้าเกลียด GitHub ก็แค่ไม่ต้องใช้ก็ได้ ผมแปลกใจที่คนเรามีเวลาพอจะรวบรวมรายการบ่นยาวขนาดนี้ได้ ถ้าไม่ได้ถูกจ้างให้ใช้มัน ก็ไปใช้อย่างอื่นสิ