จำนวนวันที่ GitHub ไม่มีเหตุขัดข้อง

 (dayswithoutgithubincident.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Days Without GitHub Incidents เป็นหน้าเว็บที่แสดงจำนวนวันที่ผ่านมาโดยไม่มี incident ของ GitHub
  • ขณะนี้บริเวณจำนวนวันแสดงเพียง ... days จึงยังไม่สามารถทราบจำนวนวันที่แน่ชัดได้
  • High Score แสดงเป็น 2026
  • ตัวเลขสำคัญที่สามารถตรวจสอบได้จากหน้าเว็บคือจำนวนวันปัจจุบันและ High Score
  • จำนวนวันปัจจุบันไม่ได้แสดงเป็นตัวเลข แต่ปรากฏในรูปแบบ ตัวแทนข้อความ

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

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

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • ช่วงนี้ได้ย้ายทุกโปรเจกต์ไปไว้บนอินสแตนซ์ Forgejo แบบโฮสต์เอง แล้ว และจนถึงตอนนี้ก็ค่อนข้างพอใจมาก มันเร็วด้วย
    ถ้ากำลังมองหาทางเลือกแทน GitHub ก็น่าลองดู อย่างน้อยก็ยังมีตัวเลือกอยู่

    • แม้จะไม่ค่อยฮิตแล้ว แต่ถ้าพูดถึงทางเลือกแทน GitHub ที่โฮสต์เองได้ Phabricator ก็สมควรได้รับการกล่าวถึงอย่างให้เกียรติ
      เอาจริง ๆ UI ที่ดู “เก่า” กลับให้ความรู้สึกเป็นข้อดี ในยุคที่ของใหม่หลายอย่างแย่ลงมาก
    • ผมรู้สึกไม่ค่อยถูกชะตากับ GitHub มาตลอด แต่ git ทำให้ประทับใจตั้งแต่ครั้งแรกที่ได้ใช้
      ผมย้ายโปรเจกต์ส่วนตัวจากอินสแตนซ์ Gitea เก่าไปที่ Forgejo แล้ว และพอใจมาก
    • แล้ว Gitea ล่ะ?

  • ผมว่าเอาทั้งแพลตฟอร์มมารวมเป็นตัวเลขเดียวมันไม่ค่อยยุติธรรม เทียบได้กับการเอา AWS ทั้งก้อน มารวมเป็นเลขเดียว

    • ในอีกมุมหนึ่ง ถ้าคุณดูแลดีพลอยเมนต์ที่ซับซ้อนพอสมควร ก็จะจมอยู่กับแดชบอร์ด CPU, หน่วยความจำ, I/O, เมตริกแอปพลิเคชัน, จำนวนผู้สมัคร, ผู้ใช้หรือเซสชันที่แอ็กทีฟได้ง่ายมาก
      เพราะงั้นการคิดหาวิธีแทนสถานะของทั้งระบบด้วย ตัวเลขเดียว จึงมีประโยชน์ เช่น เอาจำนวนเซสชันผู้ใช้ที่แอ็กทีฟไปหารด้วยจำนวนการเชื่อมต่อฐานข้อมูล แล้วปรับตามขนาดหน่วยความจำ
      ถ้ามันเป็นเลขหลักเดียว คุณก็จะคุ้นกับช่วงค่าปกติได้ และแปะไว้ในที่ที่มองเห็นชัดตลอดเวลาได้ ถึงมันจะไม่บอกรายละเอียด แต่ถ้าค่าเปลี่ยนก็ค่อยลงไปดูเมตริกเฉพาะได้ ดังนั้นในฐานะตัวย่อสำหรับเช็กพื้นฐานว่า “ปกติดีไหม?” มันก็ใช้ได้ดี
    • ถ้าหน้าสถานะแยกย่อยแบบตอนนี้ ถึงขั้นติดตามปัญหา git push กับ git pull แยกกัน แล้วสิ่งนั้นก็เป็นได้แค่มุกตลกที่มีการพูดเกินจริงนิดหน่อย แบบนั้นมันใกล้เคียงกับ การลวงตาและการปั่น SLA ให้ดูดีเกินจริง และไม่ควรปล่อยผ่าน
      มีองค์ประกอบหลักอย่าง Git, issues, pull requests, Actions ที่แทบทุกคนใช้ และถ้าพังไปอย่างใดอย่างหนึ่งก็ถือว่าเว็บไซต์พังแล้ว หน้าสถานะควรสะท้อนให้เห็นว่าเรื่องแบบนี้เกิดบ่อยแค่ไหน
    • อันนี้มันเป็นเว็บมีมชัด ๆ และยิ่งตัวเลขต่ำ มีมก็ยิ่งตลก ถ้าใครต้องการข้อมูลที่แม่นยำจริง ๆ ก็คงไปดูหน้าสถานะทางการ
    • แค่ S3, EC2, EKS และ RDB อย่างเดียว ถ้ามีอัปไทม์พอ ๆ กับ GitHub ทั้งระบบในตอนนี้ ทุกคนคงรู้กันหมดแล้ว
      ถ้า repository wiki, สถิติคอมมิต หรือ gist มีปัญหา มันก็ไม่ได้สำคัญมาก สิ่งสำคัญคือชุดบริการอย่าง PR, Actions, Discussions ที่ถูกใช้งานร่วมกันและพึ่งพากัน
      ต่อให้ทำเปอร์เซ็นต์เดียวให้กับแต่ละองค์ประกอบของทั้งสองระบบ GitHub ก็น่าจะยังแพ้อยู่ดี อาจมีจำนวนวันที่ไม่ล่มมากกว่าอยู่ไม่กี่วัน แต่นี่ไม่ใช่การเปรียบเทียบแบบง่าย ๆ
    • จากมุมมองผู้ใช้ การคำนวณแบบนี้ก็สมเหตุสมผล แต่สำหรับฝั่ง MSFT หรือ GitHub ตัวเลขนี้เป็น ตัวชี้วัดที่น่าอึดอัด พอตัว
      พวกเขาคงอยากให้ผู้ใช้ใช้ทุกฟีเจอร์ของแพลตฟอร์มและเกิดการผูกติดอย่างแน่นแฟ้น แต่ถ้าบางส่วนเสียอยู่เรื่อย ๆ ผู้ใช้ก็ยากจะมั่นใจพอที่จะใช้ฟีเจอร์เพิ่ม
      ยิ่งใช้หลายอย่าง โอกาสที่สักอย่างจะมีปัญหาก็ยิ่งสูง แต่สำหรับบริษัทแบบนี้ดูเหมือนความเสถียรจะไม่ใช่เป้าหมายอีกต่อไปแล้ว

  • สำหรับเรา นี่เป็นปัญหา ความต่อเนื่องทางธุรกิจ จริง ๆ เราผูกกับ GitHub Enterprise อยู่พอสมควร แต่ถ้ายังเป็นแบบนี้ต่อไป เราอาจต้องย้ายจากคลาวด์กลับไปออนพรีม

    • ถ้าจะไปทางนั้น ก็ควร แคช Actions ที่ต้องใช้ทั้งหมดไว้ในเครื่อง ไม่อย่างนั้นก็ไม่ได้ดีขึ้นมากนัก

  • ตอนนี้กำลังตั้งค่า Knot แบบโฮสต์เอง เพื่อใช้บน tangled.org
    เหตุผลหลักคือ AtProto มันเจ๋งและการโฮสต์เองก็สนุก แต่ก็เพราะอยากขยับไปในทิศทางที่เป็นเจ้าของอินฟราที่โฮสต์โปรเจกต์ของตัวเองด้วย
    ระบบ Knot ของ Tangled ให้ความรู้สึกเหมือนเป็น abstraction ที่แข็งแรงในเรื่องนี้ ข้อมูลถูกโฮสต์ใน AtProto Repository แต่การโฮสต์และดูแล AtProto Application ที่เอาข้อมูลนั้นมาแสดงให้โลกเห็น สามารถมอบให้บุคคลที่สามดูแลได้
    ต่อให้ Tangled หายไป ก็แค่ย้าย AtProto login ไปแพลตฟอร์มอื่นแล้วชี้มาที่ Knot ของผมได้ โดยยังคงค่าการโฮสต์เดิมไว้ได้ สะดวกกว่าการต้องโฮสต์เว็บแอปทั้งก้อนด้วยตัวเองในมุมเล็ก ๆ ของอินเทอร์เน็ตมาก

  • ในนี้มีคนออกมาปกป้อง GitHub เยอะมาก การออกมาปกป้อง บริษัทระดับหลายพันล้านดอลลาร์ ก็ดูแปลกอยู่แล้ว โดยเฉพาะเมื่อมันเป็นบริษัทที่ถือครองซอฟต์แวร์โอเพนซอร์สส่วนใหญ่แบบท่วมท้น
    อาจเป็นเพราะความรู้สึกดีที่สะสมมา แต่การที่ต้องยอมรับการเมืองภายในและวิธีทำงานของบริษัทใหญ่เพื่อจะได้มีส่วนร่วมกับโปรเจกต์ที่คุณรัก ก็เป็นเรื่องที่กลืนยากมาตลอด ผมไม่เคยรู้สึกว่าติดหนี้ GitHub
    ยิ่งไม่ใช่เลยถ้าพวกเขาทำหน้าที่ฝั่งตัวเองในข้อตกลงไม่ได้ แลกกับ Azure credits มูลค่ามหาศาล พวกเขาก็ได้เข้าถึงคลังซอฟต์แวร์ของโลกอย่างเสรี

    • ถ้ากลับคำถามกัน เหตุผลที่คุณต่อต้าน GitHub มันมากพอจริงหรือที่จะมองว่ามนุษย์ร่วมโลกที่พยายามประคองระบบอยู่ ไม่สมควรได้รับแม้แต่ ความเมตตาและความเคารพ ขั้นพื้นฐาน?
      เราแยกตัวบริษัทออกจากคนที่ทำงานหนักอยู่เบื้องหลังไม่ได้หรือ?
      พวกเขาเองก็ไม่ได้ไม่รู้ว่าคนแบบเราพึ่งพาระบบของเขาอยู่ พวกเขารู้ว่าบริการของตัวเองเป็นเหมือน “เสียงสัญญาณเชื่อมต่อ” ของขีดความสามารถในการพัฒนาซอฟต์แวร์ทั้งโลก และรับรู้ถึงผลกระทบนั้นอย่างอ่อนไหว
      แล้ว #hugops หายไปไหน? หรือมันหายไปทันทีเพียงเพราะคนเหล่านั้นทำงานให้บริษัทที่คุณไม่ชอบ?
    • ให้พูดให้ตรงคือกำลังปกป้อง Microsoft ซึ่งเป็น บริษัทระดับหลายล้านล้านดอลลาร์
    • ผมว่ามันขึ้นอยู่กับว่าคุณจ่ายเงินใช้หรือเปล่า ถ้าคุณจ่าย คุณก็ควรคาดหวังสูงและเรียกร้องความรับผิดชอบได้
      ถ้าคุณใช้บริการฟรี ความโกรธก็ยังสมเหตุสมผล แต่ในเวลาเดียวกันคุณก็ได้รับตามที่จ่ายเช่นกัน
    • น่าประหลาดใจที่ ภาพลักษณ์ต่อ GitHub หลังการเข้าซื้อกิจการ แทบไม่ได้เปลี่ยนไปเท่าไร
      พอรวมกับ WSL แล้ว หลายคนก็เหมือนเริ่มให้ Microsoft กลับมาอยู่ในฝั่ง “ลองเชื่อดูอีกครั้ง”
      แต่เหตุการณ์นี้กำลังลบล้างความรู้สึกดีที่ผ่านมาไปมาก ไม่ใช่แค่ค่าใช้จ่ายในการดำเนินงานเท่านั้น จู่ ๆ ข่าวเสียก็เริ่มเด่นขึ้นและเมินได้ยากขึ้น
    • มีอยู่สองกลุ่มที่ชอบออกตัวปกป้อง บริษัทหลายพันล้านดอลลาร์ แบบถวายชีวิต คือผู้ใช้ HN กับแฟน Nintendo

  • เขาว่าจำนวนคอมมิตบน GitHub เพิ่มขึ้น 14 เท่า เมื่อเทียบกับปีก่อน

    • พวก AI agent กำลังสแปมดันของพวกนี้เข้ามาหรือเปล่า?
    • คอมมิตหรือพุชกันแน่? ถ้ามองในแง่การวัดโหลด จำนวนคอมมิต ไม่ใช่ตัวชี้วัดที่มีความหมายมากนัก
    • 14 เท่านี่บ้ามาก โดยเฉพาะเมื่อคุณภาพและปริมาณของซอฟต์แวร์โลกจริงแทบไม่ได้ขยับตาม
      เดิมทีอาจหวังได้ว่าความสามารถในการเขียนโค้ดแบบเอเจนต์ที่เพิ่งได้มาจะสร้างคุณค่าจริงและยกระดับคุณภาพได้ แต่สิ่งที่เห็นกลับเป็น enshittification กับความซบเซา แล้วโทเคนมหาศาลพวกนี้กำลังทำอะไรกันอยู่แน่?
    • แล้วที่บอกว่าคอมมิตบน GitHub เพิ่มขึ้น 14 เท่าเมื่อเทียบปีก่อน มันแล้วไง?
      ถ้า Microsoft ยังสเกลไม่ได้ แล้วใครจะสเกลได้? ถ้ายังให้บริการไม่ได้ก็ควรหยุดขายจนกว่าจะพร้อม
      นี่มันเหมือนเหตุโกลาหลสัญญาณสายไม่ว่างของ AOL dial-up ช่วงกลางทศวรรษ 90 อีกครั้ง ต่างกันแค่ว่าคราวนี้แทนที่คนจะโกรธ กลับพากันหาข้อแก้ตัวให้บริษัทมูลค่าระดับล้านล้านที่น่าสงสารและถูกใช้งานหนัก
    • ผมไม่เข้าใจจริง ๆ เวลามีคนบอกว่านี่เป็นเพราะ AI commit และเป็นแค่เรื่องปริมาณทราฟฟิกทั้งหมด
      การเพิ่มขึ้นของ โหลดราวเลขหลักเดียว คือประมาณ 14 เท่า ไม่ควรทำให้เกิดปัญหาระดับนี้
      ถ้าเทียบสิ่งที่ GitHub ทำและปริมาณงานที่รองรับ กับบริษัทโซเชียลมีเดีย บริษัทชำระเงิน หรือแพลตฟอร์มวิดีโอ คำอธิบายว่าเป็นแค่ปัญหาโหลดล้วน ๆ ก็ดูไม่สมเหตุสมผล
      มันดูใกล้เคียงกับการที่แพลตฟอร์มมีปัญหาพื้นฐานอยู่ก่อนแล้ว และพอโหลดเพิ่มก็ยิ่งขยายปัญหานั้นมากกว่า

  • มุกนี้ใช้ได้ผลเพราะทุกคนต่างยอมรับ ความเสี่ยงจากการรวมศูนย์ ไว้เงียบ ๆ เพื่อแลกกับความสะดวก

  • https://repo.autonoma.ca/treetrek
    นี่คือ raw Git viewer ที่ผมทำเอง เป็นโอเพนซอร์สฟรี ฟีเจอร์น้อย ไม่มีแคช ไม่มี dependency ไม่มี authentication/authorization และเขียนด้วย PHP ล้วน ๆ
    ผมทำมันขึ้นมาเพราะ GitList มีบั๊กเรื่องแคชจนทำให้พื้นที่ดิสก์และหน่วยความจำของ shared hosting พัง และผมอยากรวม repository จาก GitHub, BitBucket, GitLab เข้าด้วยกัน
    การโฮสต์เองและไม่ต้องขึ้นอยู่กับอารมณ์เปลี่ยนไปมาของบุคคลที่สาม มันให้ความรู้สึกคุ้มค่าอยู่เหมือนกัน

  • มีความเป็นไปได้สูงว่าแอปนี้ ซึ่งก็น่าจะเป็นแค่ แอป vibe coding อีกตัวหนึ่ง กำลังมีส่วนช่วยให้ GitHub ล่มลงจากการถาโถมของแอป vibe coding เหล่านี้ด้วย
    ก็อดสงสารพนักงาน GitHub ที่พยายามประคองเรือที่กำลังจมให้ลอยต่อไปไม่ได้ ขณะที่ Microsoft ดูเหมือนจะทำทุกอย่างเท่าที่ทำได้เพื่อจมเรือตัวเอง