ย้ายออกจาก GitHub ไป Forgejo

 (jorijn.com)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เหตุผลโดยตรงที่ย้ายออกจาก GitHub ไม่ใช่เหตุขัดข้องในเดือนเมษายน 2026 แต่เป็นปัญหาเรื่องความเป็นเจ้าของโค้ดและเวิร์กโฟลว์ที่ทำงานอยู่บน GitHub
  • หลังเดือนสิงหาคม 2025 GitHub ไม่มี CEO ของตัวเองอีกต่อไป และถูกรวมเข้าเป็นส่วนหนึ่งของ Microsoft CoreAI division ทำให้โค้ดไปอยู่ภายใต้องค์กร AI ของ Microsoft
  • ตั้งแต่เดือนเมษายน 2026 เป็นต้นไป Copilot Free, Pro และ Pro+ เปลี่ยนเป็นโครงสร้างแบบ opt-out ที่ใช้ข้อมูลการโต้ตอบเป็นข้อมูลฝึกสอนโดยค่าเริ่มต้น
  • GitHub และ Microsoft เป็นบริษัทสหรัฐฯ จึงอยู่ภายใต้เขตอำนาจของ FISA 702 และ CLOUD Act และการมี EU data residency เพียงอย่างเดียวก็ไม่ช่วยแก้ปัญหา
  • Forgejo v15 LTS รันอยู่บน NUC เครื่องเดียวของ code.jorijn.com โดยแยก runner ด้วย KVM, gVisor, การ rebuild รายสัปดาห์ และ egress filter

เหตุผลที่ออกจาก GitHub ไม่ใช่เรื่องล่ม แต่เป็นเรื่องความเป็นเจ้าของ

  • เหตุขัดข้องในเดือนเมษายน 2026 ร้ายแรงพอสำหรับนักพัฒนา แต่เหตุผลหลักที่ย้ายออกจาก GitHub ไม่ใช่ตัวเหตุขัดข้องเอง แต่เป็นความเป็นเจ้าของของโค้ดและเวิร์กโฟลว์ที่รันอยู่บน GitHub
  • เมื่อวันที่ 27 เมษายน 2026 กระทรวงมหาดไทยของเนเธอร์แลนด์เปิดใช้งานแบบ soft launch สำหรับ code.overheid.nl ซึ่งเป็น Forgejo instance แบบ self-hosted สำหรับซอร์สโค้ดภาครัฐ
    • ผู้จัดการโครงการ Boris Van Hoytema ระบุว่าแพลตฟอร์มนี้เริ่มต้นจากข้อกำหนดที่ว่าหน่วยงานภาครัฐต้องเผยแพร่ซอร์สโค้ดใน “สถานที่ที่เป็นเจ้าของตามกฎหมาย”
    • Forgejo ถูกเลือกก่อน GitLab เพราะเป็นโอเพนซอร์สอย่างสมบูรณ์และมอบเสรีภาพที่จำเป็นต่ออธิปไตยดิจิทัล
  • โฮสต์ Git เริ่มต้นสำหรับโค้ดส่วนตัวก็ย้ายไปที่ code.jorijn.com แล้วเช่นกัน โดยรัน Forgejo v15 LTS บนการตั้งค่าที่เสริมความแข็งแกร่งบน NUC เครื่องเดียว
    • บาง repository ย้ายไปแล้ว และที่เหลือยังรอดำเนินการ
    • เมื่อการย้ายเสร็จสิ้น จะ archive repository สาธารณะบน GitHub และให้แต่ละ archive ชี้ไปยังตำแหน่งใหม่

เหตุขัดข้องและภาระจาก AI

  • เมื่อวันที่ 23 เมษายน 2026 เส้นทางโค้ด squash-merge ของ merge queue ได้ย้อนคืน commit ที่ merge ไปแล้วอย่างเงียบ ๆ ใน 658 repository และ 2,092 pull request หลังการ rollout ฟีเจอร์แฟลกที่ไม่สมบูรณ์
    • บริษัทอย่าง Modal และ Zipline ต้องกู้ข้อมูลกลับด้วยตนเอง
    • สี่วันต่อมา Pull Requests, Issues และ Packages หยุดให้บริการนานกว่า 6 ชั่วโมงจาก Elasticsearch cluster ที่โอเวอร์โหลด
  • เฉพาะเดือนกุมภาพันธ์ 2026 เดือนเดียว มีการบันทึกเหตุการณ์ขัดข้อง 37 ครั้ง รวมถึงเหตุขัดข้องยาว 3 ชั่วโมง 40 นาทีที่ Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot และ Pages ล่มพร้อมกัน
  • วันที่ 1 ตุลาคม 2025 ยังเกิดเหตุขัดข้องของ macOS runner นาน 10 ชั่วโมงอีกด้วย
  • ตามการรวบรวมของ IncidentHub ระหว่างเดือนพฤษภาคม 2025 ถึงเมษายน 2026 GitHub มีเหตุการณ์ขัดข้อง 257 ครั้งและเหตุขัดข้องใหญ่ 48 ครั้ง รวมเวลาหยุดทำงานราว 112 ชั่วโมง
  • GitHub CTO Vlad Fedorov ขอโทษเมื่อวันที่ 28 เมษายน พร้อมระบุว่าหากจะรองรับภาระจาก “agentic AI workflow growth” ตั้งแต่เดือนธันวาคม 2025 เป็นต้นมา จำเป็นต้องเพิ่มความจุถึง30 เท่า
    • ปัญหาด้านความน่าเชื่อถือจึงถูกมองได้ว่าเป็นผลข้างเคียงจากการขยายฟีเจอร์ AI
    • GitHub ยังคงเดินหน้าผลักดันฟีเจอร์ AI หนักขึ้น แทนที่จะชะลอ
  • The Pragmatic Engineer ชี้ว่า GitLab, Bitbucket, Vercel, Linear และ Sentry ไม่ได้เจอปีแบบเดียวกัน
    • บริการเหล่านี้ก็เผชิญแรงกดดันจากความต้องการของนักพัฒนาเช่นกัน ดังนั้นรูปแบบการล่มของ GitHub จึงดูเป็นปัญหาเฉพาะของ GitHub เอง

การเปลี่ยนแปลงเชิงองค์กรของ GitHub

  • เมื่อวันที่ 11 สิงหาคม 2025 Thomas Dohmke ลงจากตำแหน่ง CEO ของ GitHub และ Microsoft ไม่ได้แต่งตั้ง CEO คนใหม่
  • GitHub ถูกดูดรวมเข้าไปใน Microsoft CoreAI division
  • รายได้ วิศวกรรม และการสนับสนุนของ GitHub รายงานต่อ Microsoft developer division ภายใต้ Julia Liuson
    • GitHub CPO รายงานต่อ VP ของ Microsoft AI platform
    • แบรนด์ยังคงอยู่ แต่ผู้นำที่เป็นอิสระได้หายไปแล้ว
  • ช่วงปี 2018 ถึง 2024 การประเมินว่า Microsoft บริหาร GitHub โดยเว้นระยะห่างพอสมควรนั้นถือว่าเป็นจริงในทางปฏิบัติ แต่หลังเดือนสิงหาคม 2025 สมมติฐานนี้ก็ยากจะคงอยู่ต่อไป
  • ตอนนี้การ push โค้ดขึ้น github.com จึงหมายถึงการ push โค้ดไปยังหน่วยงานที่อยู่ภายใต้องค์กร AI ของ Microsoft

การเปลี่ยนค่าเริ่มต้นของข้อมูลฝึกสอน Copilot

  • เมื่อวันที่ 25 มีนาคม 2026 GitHub ประกาศการเปลี่ยนแปลงนโยบายความเป็นส่วนตัว ที่มีผลตั้งแต่วันที่ 24 เมษายน
    • ข้อมูลการโต้ตอบของผู้ใช้ Copilot Free, Pro และ Pro+ โดยเฉพาะ input, output, code snippets และบริบทที่เกี่ยวข้อง จะถูกนำไปใช้ฝึกและปรับปรุงโมเดล AI เว้นแต่ผู้ใช้จะเลือกปฏิเสธ
  • การเปลี่ยนแปลงสำคัญคือเป็นopt-out ไม่ใช่ opt-in
    • ผู้ใช้ Copilot Free, Pro และ Pro+ จะมีส่วนช่วยฝึกโมเดล เว้นแต่จะปิดในการตั้งค่า Copilot
  • ไม่มีการบล็อกในระดับ repository
    • ผู้ดูแลระบบไม่สามารถระบุให้ GitHub ห้ามนำการโต้ตอบภายใน repository บางแห่งไปใช้ฝึกได้
    • การ opt-out เป็นการตั้งค่าระดับบัญชีผู้ใช้ ดังนั้นผู้ร่วมพัฒนาแต่ละคนต้องเลือกเอง
    • ผลลัพธ์คือถ้าผู้ใช้ Copilot Free/Pro/Pro+ เข้ามาจัดการ repository ก็มีโอกาสที่ codebase จะกลายเป็นวัตถุดิบฝึกสอน ไม่ว่าไลเซนส์จะเป็นแบบใด
  • ข้อยกเว้นสำหรับ repository ส่วนตัวก็ถูกใช้ในวงแคบ
    • GitHub ระบุว่าจะไม่นำเนื้อหาของ repository ส่วนตัวที่อยู่ “at rest” ไปใช้ฝึก
    • แต่จะเก็บ “code snippets and interaction context” ที่เกิดขึ้นระหว่างการใช้ Copilot ภายใน repository ส่วนตัว
    • เส้นแบ่งระหว่าง “โค้ดที่อยู่นิ่ง” กับ “ชิ้นส่วนที่เกิดขึ้นระหว่างการแก้ไข” นั้นไม่ชัดเจน
  • ลูกค้า Copilot Business และ Copilot Enterprise ได้รับการยกเว้น เพราะอยู่ภายใต้ Data Protection Agreements แยกต่างหาก
    • โครงสร้างนี้จึงกลายเป็นว่า ถ้าจ่ายมากพอ การโต้ตอบจะไม่ถูกใช้เป็นข้อมูลฝึกสอน แต่ถ้าไม่จ่ายก็จะถูกใช้
  • ความสนใจเชิงกลยุทธ์ของ GitHub ต่อข้อมูลการโต้ตอบของผู้ใช้จึงไม่ใช่องค์ประกอบแบบเลือกได้อีกต่อไป แต่กลายเป็นองค์ประกอบเชิงโครงสร้าง

ความเสี่ยงด้านเขตอำนาจศาลไม่สามารถแก้ได้ด้วยตำแหน่งที่ตั้งของข้อมูล

  • GitHub Inc. และ Microsoft Corp. เป็นบริษัทสหรัฐฯ และข้อมูลที่บริษัทเหล่านี้ถือครองอยู่ภายใต้ขอบเขตของกฎหมายสหรัฐฯ รวมถึง FISA Section 702 และ CLOUD Act ปี 2018
    • กฎหมายทั้งสองฉบับนี้อาจมีผลบังคับใช้ได้ไม่ว่าข้อมูลจะอยู่ที่ใดทางกายภาพ
  • Section 702 ได้รับการต่ออายุอีก 2 ปีเมื่อวันที่ 4 เมษายน 2024 และยังคงมีผลผ่านการขยายเวลา 45 วันที่ลงนามในปลายเดือนเมษายน 2026
    • อนุญาตให้หน่วยข่าวกรองสหรัฐฯ เก็บรวบรวมข้อมูลที่มุ่งเป้าไปยังบุคคลที่ไม่ใช่ชาวอเมริกันผ่านผู้ให้บริการสื่อสารอิเล็กทรอนิกส์ที่ตั้งอยู่ในสหรัฐฯ
  • CLOUD Act สามารถบังคับให้บริษัทที่มีสำนักงานใหญ่ในสหรัฐฯ ส่งมอบข้อมูลได้ไม่ว่าข้อมูลนั้นจะถูกเก็บไว้ที่ใดในโลก
  • GitHub ประกาศ เปิดให้ใช้งานทั่วไปของ EU data residency สำหรับ Enterprise Cloud เมื่อเดือนตุลาคม 2024
    • สิ่งนี้จัดการปัญหาเรื่องตำแหน่งที่ตั้งของข้อมูล แต่ไม่ได้แก้ปัญหาเรื่องเขตอำนาจศาล
    • การเปิดรับความเสี่ยงจาก CLOUD Act ขึ้นอยู่กับโครงสร้างการควบคุมขององค์กร ไม่ใช่ตำแหน่งทางภูมิศาสตร์
  • ทนายความฝ่าย Microsoft ให้การภายใต้คำสาบานในการไต่สวนของวุฒิสภาฝรั่งเศสเมื่อเดือนมิถุนายน 2025 ว่า ไม่สามารถรับประกันได้ว่าข้อมูลของฝรั่งเศสที่เก็บไว้ในดาต้าเซ็นเตอร์ของ Microsoft ในยุโรปจะปลอดภัยจากการเข้าถึงอย่างเงียบ ๆ ของรัฐบาลสหรัฐฯ
  • ตราบใดที่โค้ดยังอยู่บน github.com โค้ดนั้นก็ยังอยู่ภายใต้ขอบเขตกฎหมายของสหรัฐฯ
    • EU data residency อาจช่วยให้สบายใจขึ้นได้ แต่ไม่ใช่คำตอบของปัญหา

การเลือก code.overheid.nl ของรัฐบาลเนเธอร์แลนด์

  • พื้นฐานทางกฎหมายของการตัดสินใจของรัฐบาลเนเธอร์แลนด์คือ นโยบาย “Open, tenzij” ซึ่งมีผลบังคับใช้มาตั้งแต่ปี 2020
    • ซอฟต์แวร์ที่พัฒนาด้วยเงินสาธารณะจะเป็นโอเพนซอร์สโดยปริยาย เว้นแต่จะมีข้อกำหนดด้านความปลอดภัยหรือความลับ
    • เพื่อให้เป็นไปตามนโยบายนี้ แต่ละกระทรวงจึงต้องมีที่เผยแพร่โค้ดในสถานที่ที่ตนควบคุมได้จริง
  • คณะกรรมาธิการยุโรปดำเนินการ code.europa.eu ซึ่งเป็นระบบที่โฮสต์เองบนพื้นฐานของ GitLab มาตั้งแต่เดือนกันยายน 2022
  • openCode ของเยอรมนีก็สร้างบน GitLab เช่นกัน
  • code.gouv.fr ของฝรั่งเศสเป็นตัวรวบรวมดัชนีของรีโพซิทอรีที่โฮสต์ไว้ที่อื่น ไม่ใช่ forge ที่โฮสต์เอง
  • รัฐบาลเนเธอร์แลนด์เลือก Forgejo โดยตั้งใจ ไม่ใช่ GitLab
    • ตามข้อมูลจาก OSOR เหตุผลคือ Forgejo เป็นโอเพนซอร์สเต็มรูปแบบ ไม่มีการแยกแบบ open-core และมอบเสรีภาพทั้งหมดที่จำเป็นต่ออธิปไตยทางดิจิทัล
    • Van Hoytema ยังเสริมว่าโรดแมปของ Forgejo “way more aligned” กับความต้องการมากกว่าทางเลือกอื่น
  • รัฐบาลเนเธอร์แลนด์ไม่ได้ต้องการแค่ forge ที่มีอธิปไตย แต่ต้องการ forge ที่มีอธิปไตยโดยไม่ถูกล็อกไว้หลัง premium tier ของผู้ขายเชิงพาณิชย์
  • รัฐบาลก็มองเห็นกรอบปัญหาแบบเดียวกันและตัดสินใจแบบเดียวกัน ทำให้การเลือก Forgejo ยากจะถูกมองว่าเป็นตัวเลือกชายขอบอีกต่อไป

เหตุผลที่เลือก Forgejo

  • GitLab ก็ถูกพิจารณาอย่างจริงจังเช่นกัน
    • GitLab CE แบบโฮสต์เองเป็นตัวเลือกที่เป็นที่รู้จักดี และมี ecosystem เชิงพาณิชย์ที่ใหญ่กว่า รวมถึง UI ที่ขัดเกลามากกว่า

  • ใบอนุญาต

    • GitLab ใช้โมเดล open core
      • Community Edition อยู่ภายใต้ใบอนุญาต MIT แต่ฟีเจอร์จำนวนมากที่ต้องการในงานปฏิบัติการจริงอยู่ใน Enterprise tier ที่ใช้ใบอนุญาตแบบไม่เสรี
    • Forgejo เดินไปในทิศทางตรงกันข้าม
      • ตั้งแต่ v9.0 ในเดือนสิงหาคม 2024 ได้มีการเปลี่ยนใบอนุญาตจาก MIT เป็น GPLv3+
      • เป้าหมายที่ประกาศไว้อย่างชัดเจนคือการรักษา copyleft และป้องกันไม่ให้ codebase ถูกครอบงำเชิงพาณิชย์ในอนาคต
    • เหตุผลที่ Forgejo fork ออกจาก Gitea ในเดือนธันวาคม 2022 ก็เพราะ Gitea Ltd ควบคุมเครื่องหมายการค้าและโดเมนโดยไม่มีฉันทามติจากชุมชน
      • บทเรียนจากเรื่องนั้นสะท้อนอยู่ในการเลือกใบอนุญาต

  • ธรรมาภิบาล

    • Forgejo อยู่ภายใต้ Codeberg e.V.
      • Codeberg e.V. เป็นองค์กรไม่แสวงหากำไรที่จดทะเบียนในเบอร์ลินมาตั้งแต่เดือนกันยายน 2018
      • มีคณะกรรมการที่สมาชิกเลือกตั้ง งบประมาณเปิดเผยต่อสาธารณะ และมีรีโพซิทอรีมากกว่า 300,000 รายการบนอินสแตนซ์ที่ให้บริการโฮสต์
    • สมาชิกลงคะแนนเรื่องงบประมาณทุกปี
      • แผนปี 2025 ได้รับการอนุมัติด้วยคะแนนเห็นชอบ 88 ไม่เห็นชอบ 0 และงดออกเสียง 1

  • การออกรีลีสและความสุกงอม

    • Forgejo v15.0 LTS เปิดตัวเมื่อ 16 เมษายน 2026
      • เป็นรีลีสลำดับที่ 100 ของโครงการ
      • การสนับสนุนระยะยาวจะต่อเนื่องไปจนถึง 15 กรกฎาคม 2027
    • Forgejo Actions ไปถึงระดับที่ใช้งานได้ตามต้องการใน v15
      • มีทั้ง ephemeral runner, OpenID Connect และ reusable workflow expansion
    • หลังการ fork โครงการก็ออกรีลีสอย่างสม่ำเสมอ และรายงานประจำเดือนก็ยังคงเคลื่อนไหวอย่างต่อเนื่อง

  • ข้อจำกัดของ ecosystem เชิงพาณิชย์

    • Forgejo มี ecosystem เชิงพาณิชย์อยู่ แต่ยังบาง
    • ผลิตภัณฑ์เชิงพาณิชย์ที่ดูลงตัวที่สุดในตอนนี้คือ Codey by VSHN
      • เป็นบริการ Forgejo แบบ managed hosting ในสวิตเซอร์แลนด์ที่เปิดตัวโดย Servala เมื่อเดือนมีนาคม 2025
      • ราคาเริ่มต้นที่ 19 CHF ต่อเดือน
    • ยังไม่มีบริการ subscription สำหรับ enterprise support แบบสไตล์ Red Hat
    • หากต้องการการสนับสนุนทางโทรศัพท์ตลอด 24/7 และผู้ขายที่รับผิดชอบโดยตรง ก็ต้องสร้างเองหรือรอไปก่อน

การตั้งค่า code.jorijn.com

  • code.jorijn.com รันอยู่บน Intel NUC เครื่องเดียวในโฮมออฟฟิศ
    • RAM คือ 64GB
    • Forgejo v15 LTS, Postgres 17 และ Traefik รันอยู่ภายใน Docker
    • KVM virtual machine ที่จัดการด้วย Incus รัน Forgejo Actions runner อยู่ข้างกัน
  • การตัดสินใจที่สำคัญยิ่งกว่าการจัดวาง Forgejo, Postgres และ reverse proxy คือการตั้งค่า runner

runner คือส่วนที่เสี่ยงที่สุด

  • ใน forge ที่โฮสต์เอง ตัว forge เองเป็นส่วนที่ง่าย ส่วนที่ยากคือสภาพแวดล้อมที่ใช้รันงาน CI
  • runner ต้องรัน npm install, composer install, pip install ทุกวันตามตารางของ Renovate
    • เป้าหมายคือ lockfile ที่สร้างจากรีโพซิทอรีของตนเอง
    • นั่นหมายถึงการรัน lifecycle script
    • ทุกงานอาจลงเอยด้วยการรันโค้ดที่ไม่น่าเชื่อถือได้
  • มีความเสี่ยงแบบเดียวกับกรณีหนอน npm ล่าสุดและการโจมตีห่วงโซ่อุปทานของ axios ที่อาศัย dependency bot ซึ่ง auto-merge ภายในหนึ่งชั่วโมง
  • หน้าที่ของ runner ไม่ใช่การรันโค้ด แต่คือการ แยกกัก โค้ดที่กำลังรันอยู่
    • การออกแบบตั้งอยู่บนสมมติฐานว่าชั้นป้องกันใดชั้นหนึ่งอาจล้มเหลวได้ และให้ชั้นถัดไปรับแรงกระแทกจากความล้มเหลวนั้น

ชั้นการป้องกันของ runner

  • เครื่องเสมือน KVM แบบถาวร

    • runner อยู่ภายใน KVM VM แยกต่างหาก ไม่ใช่คอนเทนเนอร์บนโฮสต์
    • สภาพแวดล้อมงานไม่ใช้เคอร์เนลของโฮสต์ร่วมกัน
    • หาก CVE ของ Linux kernel ภายใน runner จะไปถึง NUC ได้ ต้องเจาะขอบเขต KVM ให้แตกก่อน

  • ใช้ gVisor เป็น Docker runtime เริ่มต้นภายใน VM

    • คอนเทนเนอร์งานรันอยู่ใต้ runsc
    • runsc จะดักจับ system call ใน user space แทนที่จะส่งตรงไปยังโฮสต์เคอร์เนล
    • การ escape ออกจากคอนเทนเนอร์ต้องเจาะทั้ง gVisor และ KVM ที่ล้อมอยู่อีกชั้นให้ได้

  • รีบิลด์แบบทำลายทิ้งรายสัปดาห์

    • ทุกวันจันทร์เวลา 02:00 UTC จะลบ VM ทั้งหมดแล้วสร้างใหม่จาก Ubuntu base image ใหม่
    • การลงทะเบียน persistent runner ใหม่สำหรับ Forgejo ก็จะถูกออกใหม่ด้วย
    • base image จะถูกรีบิลด์ในวันอาทิตย์ ดังนั้น VM ใหม่จะรวม apt และ kernel patch ของสัปดาห์นั้น
    • สถานะแบบ persistent จะคงอยู่ได้นานไม่เกิน 7 วัน

  • ตัวกรอง egress ของ nftables บน runner bridge

    • runner เข้าถึงปลายทางสาธารณะได้ที่ :443, :80, :22, :53
      • เป้าหมายได้แก่ npm, pypi, ghcr และ Forgejo ของตัวเองที่เข้าผ่าน public hostname ด้วย hairpin NAT
    • ไม่สามารถเข้าถึง 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 ได้
    • งานที่ถูกเจาะจะไม่สามารถสแกน LAN หรือเข้าถึงหน้าแอดมินของเราเตอร์หรือบริการอื่นบนโฮสต์ได้

  • runner token แบบจำกัดขอบเขต

    • การลงทะเบียน persistent runner สองรายการจะถูกผูกกับขอบเขตผู้ใช้เดียวและขอบเขตองค์กรเดียวตามลำดับ
    • การจัดการใช้ PAT scope write:user,write:organization
    • token ที่รั่วไหลจะไม่สามารถลงทะเบียน runner นอกขอบเขตได้ และทำงานระดับ admin scope ก็ไม่ได้
    • ชั้นต่าง ๆ ถูกออกแบบให้ซ้อนทับกันโดยตั้งใจ
    • แต่ละชั้นคือรั้วกั้น และเมื่อรวมกันจะกลายเป็นขอบเขตการป้องกันเชิงลึก
    • KVM isolation, gVisor, การรีบิลด์รายสัปดาห์, และการลงทะเบียน runner แบบผูกขอบเขต ล้วนเป็นสิ่งที่ Forgejo และ Incus รองรับอยู่แล้วโดยพื้นฐาน

สิ่งที่ยอมเสียไป

  • การถูกค้นพบและ social graph

    • GitHub คือที่ที่ผู้มีส่วนร่วมใช้ค้นหา repository
    • คนที่อยากส่งการแก้ไขเล็ก ๆ ให้ public repository มักคาดหวังว่าจะทำบน github.com ไม่ใช่โดเมนที่ไม่คุ้นเคย
    • เมื่อย้ายเสร็จแล้ว มีแผนจะ archive public GitHub repository แต่ละอัน และให้ README ชี้ไปที่ code.jorijn.com
    • เส้นทางการค้นพบยังคงอยู่
      • ผู้คนยังคงหา repository เจอผ่าน GitHub แล้วเห็นข้อความใน archive ก่อนย้ายไปยัง canonical home
    • ตอนนี้ยังทำไม่เสร็จ และมีเพียงบาง repository เท่านั้นที่อยู่บน code.jorijn.com ส่วนที่เหลือยังรอการย้าย

  • ความเข้ากันได้ที่เปราะบางของ ecosystem ของ GitHub Actions

    • Forgejo Actions ตั้งเป้าที่ความคุ้นเคย ไม่ใช่ความเข้ากันได้เต็มรูปแบบ
    • ส่วนใหญ่ใช้งานได้ แต่บางอย่างใช้งานไม่ได้
    • บล็อก permissions: ระดับ workflow จะถูกเมินอย่างเงียบ ๆ
    • actions/checkout@v6 ทำให้ authenticated checkout บน runner ที่ไม่ใช่ GitHub พังในช่วงต้นปี 2026 จึงต้องตรึงไว้ที่ v5
    • actions/upload-artifact@v4 ต้องใช้ fork ที่โฮสต์โดย Forgejo
    • OIDC ใช้งานได้ แต่ใช้ workflow key คนละตัวคือ enable-openid-connect: true แทน permissions: id-token: write ของ GitHub
    • ถ้า workflow พึ่งพาฟีเจอร์เฉพาะของ GitHub มาก การย้ายจะไม่ใช่งานที่จบในเย็นเดียว แต่จะกลายเป็นโปรเจ็กต์

  • การไม่มี Dependabot

    • Forgejo ไม่มี Dependabot
    • ใช้ Renovate รันทุก 3 ชั่วโมงบน runner แบบ self-hosted ตัวเดียวกัน
    • มันทำหน้าที่เดียวกันได้ แต่ต้องตั้งค่าเยอะกว่า และใช้เวลาทั้งวันในการคอนฟิก

  • การซัพพอร์ตจากผู้ขายตลอด 24/7

    • GitHub Enterprise ให้ทั้งเบอร์โทรและ SLA
    • Forgejo ให้ issue tracker และห้องแชต
    • สำหรับการดูแลโดยคนเดียวถือว่าเพียงพอ แต่อาจไม่พอสำหรับองค์กรวิศวกร 200 คน

กรณีที่ไม่คุ้มจะย้าย

  • ถ้าทีมไม่มีทั้งความตั้งใจหรือความสามารถในการดูแลโครงสร้างพื้นฐานเองเลย ก็ควรหลีกเลี่ยงการย้ายไป Forgejo แบบ self-hosted
    • Forgejo แบบ managed อย่าง Codey หรือ Codeberg สำหรับ FOSS ช่วยลดช่องว่างไปได้มาก แต่ต้นทุนการย้ายก็ยังคงมีอยู่
  • ถ้าลงทุนกับ ฟีเจอร์เฉพาะของ GitHub อย่าง GitHub Apps marketplace, Codespaces, Copilot Workspace หรือ Advanced Security ไว้ลึกมาก ก็ไม่เหมาะ
    • Forgejo เป็น forge ไม่ใช่ developer-platform-as-a-service
  • ถ้าฐานผู้มีส่วนร่วมของคุณผูกกับ social graph ของ GitHub การถูกค้นพบอาจสำคัญกว่าการเป็นเจ้าของ
    • คุณอาจเลือกอยู่ตรงที่ผู้มีส่วนร่วมอยู่ หรือยอมรับแรงเสียดทานแล้วย้ายให้เสร็จ จากนั้น archive public GitHub repository แล้วชี้ไปยังที่อยู่ใหม่ ก่อนจะกลับมาประเมินอีกครั้งภายหลัง
  • ถ้ายังไม่มีคำตอบด้านการปฏิบัติการที่น่าเชื่อถือสำหรับ runner ก็ย้ายได้ยาก
    • นี่คือส่วนที่ต้องถูกจัดการอย่างจริงจังที่สุด
    • ถ้ายังไม่พร้อมคิดเรื่อง KVM isolation, gVisor, nftables และการรีบิลด์รายสัปดาห์ ก็ควรรันงาน CI บน managed runner host หรืออยู่กับ GitHub ต่อไป
  • แม้แต่รัฐบาลเนเธอร์แลนด์ก็ไม่ได้ย้ายทุกอย่างในครั้งเดียว
    • code.overheid.nl เป็นแพลตฟอร์มเปิดตัวแบบ soft launch สำหรับให้หน่วยงานภาครัฐแชร์โค้ดโอเพนซอร์ส ไม่ใช่การแทนที่ทุกสิ่งที่ใช้อยู่แบบเต็มรูปแบบ
    • การตั้งค่า code.jorijn.com ก็เป็นรูปแบบเดียวกัน
      • Forgejo เป็น canonical host ส่วน GitHub เป็น mirror และจะกลับมาประเมิน mirror ใหม่ในภายหลังได้

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

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

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

  • ดูเหมือนทุกคนจะ ออกจาก GitHub จนลืมจิตวิญญาณดั้งเดิมของ git
    เดิมที git ตั้งใจให้กระจายศูนย์ ปัญหาคือ GitHub สะอาดตากว่า ขยายระบบได้ดีกว่า และดูแลจัดการได้ดีกว่า จนเครื่องมือรอบ ๆ git ทั้งหมดถูกรวมศูนย์ไปที่ GitHub
    ถึงอย่างนั้นก็ยังอยากให้มี mirror ที่ซิงก์อัตโนมัติไปยัง GitHub อยู่ เพราะตลอดหลายปีที่ผ่านมาเคยเห็นโปรเจ็กต์ย้ายไป self-host หรือโฮสต์เฉพาะทาง แล้ว GitHub mirror ก็ตายหรือถูกลบ สุดท้ายโปรเจ็กต์ก็หายไปตามกาลเวลา
    git เป็นระบบกระจายศูนย์ และ GitHub ก็เป็นเพียงหนึ่งในสถานที่ที่เอาโค้ดไปวางได้เท่านั้น อีกทั้งยัง push ไปหลาย remote server ได้

    • ไม่ได้ลืมจิตวิญญาณของ git หรอก แต่ก็ยังจำได้ว่า GitHub เอา รีโพสาธารณะทั้งหมด ไปฝึก Copilot รุ่นแรกโดยไม่บอกใคร
      เพราะงั้นฉันจะไม่ commit โค้ดส่วนตัวลงไปที่นั่นอีกแล้ว
      ฉันก็ไม่ได้สนใจฟีเจอร์เชิงสังคมอย่างการถูกค้นพบ star หรือ issue ที่ AI bot ถล่มเข้ามา ตอนนี้สภาพแบบนี้ก็พอแล้ว
      และต้องจำไว้ด้วยว่า “Open Source is not about You”
    • จริง แต่ GitHub ไม่ได้มีแค่ git
      สิ่งสำคัญที่สุดของแพลตฟอร์มที่ทุกคนลืมคือองค์ประกอบทางสังคม และการที่มันทำให้สร้าง external repository แบบถาวรได้ รวมถึงทำให้การร่วมมือกันข้ามรีโพง่ายมาก
    • Forgejo กำลังทำงานอย่างหนักเพื่อกระจายศูนย์ไปถึงระดับเครื่องมือด้วย
      มันใช้โปรโตคอลและมาตรฐานแบบเปิดเพื่อเชื่อม forge ที่ self-host กันเองเข้าหากัน
    • ไม่ใช่ทุกคนจะใช้ git เพราะหลงใหลใน “จิตวิญญาณของ git”
      มีคนจำนวนน้อยมากที่เคยใช้มันในโมเดล email patch ตามที่ตั้งใจไว้แต่แรก และคนส่วนใหญ่ที่เหลือก็คงไม่ได้คิดจะเรียนรู้มันด้วย
      โดยพื้นฐานแล้วคนใช้ git เพราะ GitHub ใช้ หรือพูดให้ใจกว้างกว่านั้นคือ เพราะมันทำงานได้ดีเมื่อจับคู่กับโฮสต์แบบรวมศูนย์อย่าง GitHub
      ผู้คนสนใจโมเดลที่พัฒนาโค้ดในเครื่อง แล้วไปคุยเรื่อง issue กับ patch บนเว็บพอร์ทัล ซึ่งส่วนที่ git เองมีให้จริง ๆ นั้นมีไม่มาก
    • เห็นด้วย ย้าย git repository นั้นง่าย แต่การย้าย พื้นผิวทั้งหมดของโปรเจ็กต์ นั้นยาก
      issue, release, CI, เอกสาร, คำแนะนำด้านความปลอดภัย, การค้นหาและการถูกค้นพบ ล้วนมีแนวโน้มถูกผูกไว้กับ GitHub เมื่อเวลาผ่านไป
      ถ้าเป็นโปรเจ็กต์โอเพนซอร์ส ฉันคิดว่าแนวทางที่ดีคือให้ self-host เป็นแหล่งความจริงหลัก แต่คง GitHub mirror แบบอ่านอย่างเดียวไว้เพื่อให้คนยังหาเจอได้จริง

  • สิ่งที่จะเปลี่ยนเกมจริง ๆ คือ การรองรับ federation ที่เสร็จสมบูรณ์
    เพราะแบบนั้นฉันถึงบริจาคให้ Forgejo และ Codeberg และอยากชวนให้ทุกคนช่วยลงเวลาและทรัพยากรเพิ่ม เพื่อให้ทีม Forgejo ทำสิ่งนี้ให้สำเร็จได้จริง
    อีกตัวเลือกที่ดีคือ Radicle ซึ่งกระจายศูนย์อย่างสมบูรณ์บน Git
    https://codeberg.org/forgejo-contrib/federation/src/branch/m...
    https://liberapay.com/forgejo
    https://donate.codeberg.org/
    https://radicle.dev/
    https://radicle.network/nodes/seed.radicle.dev

    • Federation เป็นโมเดลการกระจายศูนย์ที่แย่ที่สุด มันหลวมเกินไปสำหรับการทำงานร่วมกัน

  • ฉันก็ย้าย git repository ของตัวเองไปไว้บน NUC ที่ self-host แล้ว
    ยังไม่ได้ติดตั้ง HTTP frontend สำหรับแชร์ให้โลกภายนอก เพราะไม่อยากป้อนคอนเทนต์ให้ AI scraper และก็ไม่อยากเสียเวลามานั่งบล็อกพวกมันด้วย
    เป็นเรื่องน่าอับอายที่บริษัทซึ่งได้ประโยชน์จากโอเพนซอร์ส กลับทำให้อุตสาหกรรมสกปรกแบบนี้

    • ฉันใช้ Gitea บน NUC และใช้ฮาร์ดแวร์มือสอง เลยเสียไปประมาณ 50 ปอนด์
      มันรันมา 3 ปีแล้ว ความรู้สึกในการใช้งานคือแข็งแรงและอยู่ทน ถ้าล็อกให้เข้าถึงได้เฉพาะใน LAN และไม่เปิดออกสู่อินเทอร์เน็ต
    • ฉันรัน Forgejo แบบ self-host บน Pi เป็น GitHub mirror อยู่ แต่คงอยู่ได้อีกไม่นาน
      repository จะ mirror ได้ดีอยู่หลายสัปดาห์แล้วก็หยุด มันอ้างว่า PAT token หมดอายุทั้งที่ฉันใส่แบบไม่หมดอายุ และลองที่อื่น token ก็ยังใช้งานได้ปกติ
      บางครั้งใน log ก็ไม่มีอะไรเลย บางครั้งก็บอกว่าฐานข้อมูลถูกล็อก ทั้งที่ Forgejo เป็นตัวเดียวที่ใช้ฐานข้อมูลนั้น
      จนถึงตอนนี้ยังแยกไม่ออกว่านี่เป็นปัญหาของ Forgejo เอง, เป็นเพราะ SD card I/O ห่วย ๆ ของ Pi จนทำให้ฐานข้อมูลล็อก, หรือ Forgejo ไม่เหมาะกับการเป็น mirror กันแน่
    • โอเพนซอร์สกับ OSI เป็นกลไกที่อุตสาหกรรมวางไว้ ดูก็รู้ว่าใครเป็นสปอนเซอร์
      บริษัทยักษ์คลาวด์แบบ proprietary ได้แรงงานฟรี แล้วเอาไปสร้างโลกที่เรารังเกียจ ทั้งเครือข่ายติดตามสอดส่อง โทรศัพท์ที่ติดตั้งอะไรก็ไม่ได้ device attestation และวัฒนธรรมเบราว์เซอร์แบบเดียวที่บล็อกโฆษณาไม่ได้
      Google ทำให้คนหลงรัก BSD/MIT แล้วก็ดูผลลัพธ์เอาเอง
      กลยุทธ์คลาสสิกอย่างหนึ่งคือ “ตอนนี้ของสิ่งนั้นเป็นของเราแล้ว” ถ้ามี vendor สร้างอะไรอย่าง Elasticsearch หรือ Redis ขึ้นมา hyperscaler ก็หยิบไปทำเป็นสินค้า proprietary ของตัวเองแล้วกวาดกำไรไปหมด ปล่อยให้ผู้เขียนต้นฉบับกับบริษัทอดอยาก
      อีกอย่างคือ “embrace, extend, extinguish” เอาโปรเจ็กต์โอเพนซอร์สอย่าง KHTML หรือ Linux ไปทำเวอร์ชันของตัวเอง กระจายออกสู่ตลาดเพื่อเบียดคู่แข่ง จากนั้นก็ใช้วิธีต่อต้านการแข่งขันเอาสินค้าตัวเองมาวางตรงหน้าทุกคน พอได้ส่วนแบ่งตลาดแล้วก็ยัดระบบติดตามและเอาเสรีภาพออกไป
      โอเพนซอร์สควรถูกแทนที่ด้วย “คนใช้ได้อย่างเสรี แต่บริษัทต้องจ่ายเงิน” เราต้องการ source-available shareware ที่มีเขี้ยวเล็บพอสู้ hyperscaler ได้
      แม้แต่ไลเซนส์ของ Richard Stallman ก็ยังไม่แข็งพอ ฉันว่า CC BY-NC-SA ยังดีกว่า
      โอเพนซอร์สแบบ “บริสุทธิ์” เป็นสวัสดิการให้บริษัท และเป็นความผิดพลาด มันเปิดทางให้ยักษ์ใหญ่เอาเชือกของเราไปใช้แขวนคอเราเอง
    • ถ้าใครเต็มใจเปิดงานของตัวเองเป็นโอเพนซอร์สอยู่แล้ว ฉันไม่เข้าใจว่าทำไมต้องขีดเส้นตรงที่ AI จะอ่านแล้วนำไปใช้เป็นความรู้ เพื่อช่วยโปรแกรมเมอร์คนอื่นต่อในภายหลัง
      ฉันอยากให้ AI มาอ่านโค้ดของฉันอย่างเต็มที่เลย

  • ในส่วน “What I gave up” ผู้เขียนพูดถึง social graph ของตัวเอง แต่ถ้าใช้ GitSocial ก็พา social graph กับประวัติการทำงานร่วมกันไปต่อได้
    มันทำให้ pull request ข้าม forge เป็นไปได้ระหว่าง git host ใด ๆ และทั้งหมดทำงานได้โดยไม่ต้องพึ่ง third-party เลย

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

  • จากประโยคที่ว่า “CTO ออกมาขอโทษต่อสาธารณะและบอกว่าต้องขยาย capacity 30 เท่าเพื่อรองรับภาระงานจาก AI” ก็หวังว่า GitHub จะไม่เริ่มเก็บเงินกับการใช้งานทั่วไป
    แต่พอเห็น vibe coder บางคนสร้าง commit หลายพันครั้งต่อวัน ก็เริ่มสงสัยมากขึ้นเรื่อย ๆ
    ถ้าเราแชร์โค้ดฟรีและร่วมมือกันไม่ได้จริง ๆ ก็คงน่าเสียดายมาก

    • เก็บเงินตาม จำนวน commit ต่อวัน หลังเกินเกณฑ์ก็พอ จบปัญหา
    • พูดตรง ๆ ฉันว่า LLM ก็น่าจะช่วยแก้ปัญหาที่พวกมันก่อขึ้นเองได้นั่นแหละ
      คนมีประสบการณ์ดู repository แบบนี้แค่ไม่กี่วินาทีก็รู้แล้วว่ามีปัญหา ดังนั้นระบบที่จูนมาดีก็น่าจะทำได้เหมือนกัน
      ส่วนที่ยากคือการเขียนข้อกำหนดทางกฎหมายให้สามารถบังคับใช้ โควตา vibe ได้
      Anthropic ทำประมาณนี้อยู่แล้วใน CC และ GitHub กับ GitLab ก็น่าจะทำคล้าย ๆ กันอยู่ ข้อเสียคืออาจโดนเกลียดจากพวกนักพัฒนา Twitter และบางส่วนของ subreddit เล็ก ๆ แต่ก็น่าจะคุ้ม
      อีกด้านหนึ่ง เวลาฉันเห็นคนใน /r/vibecoding จ่ายค่าสมาชิกรายเดือน 200 ดอลลาร์ เพื่อทำโปรเจ็กต์งานอดิเรกหรือเว็บของเล่นที่ใกล้เคียงแค่นั้นอยู่บ่อย ๆ ก็รู้สึกทึ่งไม่น้อย
      ฉันเองก็เคยใช้เงินโง่ ๆ ตอนพอยังรับไหว แต่เรื่องนี้ให้ความรู้สึกต่างออกไปนิดหน่อย
      บางทีมันอาจเป็นการจ่ายปีละ 2400 ดอลลาร์เพื่อซื้อความหมายและจุดมุ่งหมาย ก็ได้ ถ้าคุณอายุราว 40 แล้วเริ่มตระหนักว่าคงไม่มีวันรวยหรือดัง มันอาจเป็นราคาที่ยังพอรับได้เมื่อเทียบกับทางเลือกอื่น

  • เคยได้ยินว่า Tangled ก็เป็นบริการกระจายศูนย์ที่สร้างบน AT Protocol แบบเดียวกับ Bluesky
    มันยังมีฟีเจอร์ที่ใช้ได้จริงอย่าง stacked pull request ซึ่ง GitHub ลากเท้าเรื่อง implementation จนมีบริษัทเกิดขึ้นมาเพื่อเอาฟีเจอร์นี้ไปใส่ใน GitHub
    อยากรู้ว่ามีใครเคยใช้ไหม
    https://tangled.org/

    • ไม่นานมานี้ฉันตั้ง Knot แบบ self-host แต่ยังไม่ได้ลองฟีเจอร์อื่นมากนัก
      https://tangled.org/h14h.com/knot
      โดยรวมแพลตฟอร์มดูมีอนาคตมาก วิธีที่ AtProto แยก personal data server, relay และ AppView ออกจากกันดูเป็นจุดลงตัวที่เหมาะสม
      คุณสามารถโฮสต์ git repository เป็นเซิร์ฟเวอร์ข้อมูลล้วนแบบ headless ได้ ดังนั้นสำหรับการ self-host แล้วแทบไม่เจ็บปวดเลย
      เทียบกับแนวทาง ActivityPub แบบ Forgejo สิ่งที่ฉันสนใจคือการควบคุมข้อมูล และมันก็ดีที่เลี่ยงความน่าเบื่อของการต้องโฮสต์และสเกลเว็บแอปทั้งชุดได้
      หลังตั้งค่าเริ่มต้นแล้ว งานดูแลรักษามีแค่อัปเกรดเวอร์ชัน knot-server แล้ว deploy ใหม่ ถ้า tangled.org เป็นเวอร์ชันเก่ามันก็จะแสดงแบนเนอร์เตือน
      ฉันอยากใช้ Tangled กับโปรเจ็กต์อื่นเพิ่มและทดสอบฟีเจอร์ด้วย โดยเฉพาะสนใจการรองรับ jj และ stacked PR แบบ native
    • มันยังเป็น ซอฟต์แวร์ระดับอัลฟา ชัด ๆ แต่ก็ใช้กับงานโอเพนซอร์สได้
      ยังมีการทดลองน่าสนใจอย่าง tack สำหรับต่อ custom CI ด้วย
      ถ้า ATProto รองรับข้อมูลส่วนตัวเมื่อไร วันหนึ่งมันก็น่าจะรองรับ private repository ได้ แต่คงต้องใช้เวลาอีกหน่อย
      https://tangled.org/mitchellh.com/tack
    • เพิ่งได้เงิน venture funding ก้อนใหญ่มา
      แต่ยังไม่พูดถึงโมเดลธุรกิจเลย ก็เลยอยากรู้จริง ๆ ว่ามันจะออกมาเป็นอะไร
    • ฉันอยากใช้เพราะรองรับ jj และมี CI implementation ที่สะอาดดี แต่ฉันต้องใช้ private repository เลยยังไม่เหมาะกับฉันตอนนี้
    • สำหรับรสนิยมฉัน มันกระจายศูนย์เกินไป
      ไปใช้ radicle.xyz แทนน่าจะดีกว่า

  • Fossil ก็น่าพิจารณาเหมือนกัน
    มันรวมสถานะทั้งหมดของ repository ไว้ในไฟล์เดียว ทั้งประวัติโค้ด วิกิ ticket และฟอรัม และสถานะนั้นก็ถูก replicate ไปด้วย
    เวลาต้องเปลี่ยนผู้ให้บริการโฮสต์ ใน Fossil จะไม่มีข้อมูลสูญหายเพราะเรื่องนั้นเลย
    https://fossil-scm.org/

    • ฉันชอบ Fossil มาก มันมีอะไรบางอย่างใน workflow แบบหัวแข็งของมันที่เข้ากับวิธีคิดของฉัน
      แต่ปัญหาคือ network effect ฉันพาทีมย้ายมา Fossil ไม่ได้
      ทีมต้องแชร์โค้ดกับคนอื่น กับแผนกอื่น และทุกคน หรือพูดจริง ๆ คือมากกว่า 99% ใช้ git กันหมด
      การบังคับให้ใช้ Fossil กลับให้ความรู้สึกเหมือนทำร้ายพวกเขา เลยกลายเป็นสถานการณ์กลืนไม่เข้าคายไม่ออก
      มันก็คล้ายกับอีกหลายเรื่องในสายเทค เช่น พยายามให้เพื่อนนักพัฒนาใช้สำนวนแบบ functional หรือบังคับใช้ immutability
      รู้สึกเหมือนต้องมีอะไรใหญ่ ๆ ระดับโปรเจ็กต์ของ Facebook หรือ Google มากระชากชุมชนให้ขยับตาม
    • ฉันเคยประเมิน Fossil เมื่อหลายปีก่อนและคิดว่ามันยอดเยี่ยมจริง ๆ การที่ทุกอย่างรวมกันมานั้นดีมาก
      แต่ในเชิงปรัชญา ฉันไม่ชอบ Fossil เพราะมันไม่มี วิธีจัดระเบียบประวัติ และเก็บทุกอย่างไว้ทั้งหมด
      ถ้านั่นคือสิ่งที่คุณต้องการก็เยี่ยม แต่สำหรับ workflow แบบ git ของฉัน ฉันชอบลองอะไรไปเรื่อย ๆ แล้วค่อยเก็บกวาดและจัด commit ให้เป็นระเบียบก่อน push

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

    • แค่อ่านบรรทัดแรกใต้ชื่อเรื่องก็น่าจะพอแล้ว: “I moved my code from GitHub to a self-hosted Forgejo”
    • การกระจายศูนย์หมายถึงการไม่มีศูนย์กลางเดียว
      เหตุผลที่คนต้องการมันก็เพราะการมีผู้ดูแลศูนย์กลางเพียงรายเดียวไม่เพียงพอด้วยเหตุผลใดเหตุผลหนึ่ง
      ไม่มีความแตกต่างระหว่างการที่คนพูดถึงมัน กับการที่คนต้องการมันจริง ๆ
    • คนอยากได้ข้อดีของการกระจายศูนย์ แต่ไม่อยากจ่ายต้นทุนของมัน
      ที่แย่กว่านั้นคือระบบรวมศูนย์มักยอดเยี่ยมเกือบตลอดเวลา และความเจ็บปวดจะมาหนักมากในช่วงสั้น ๆ อย่างตอนควบรวมหรือขึ้นราคาแบบฉับพลัน
      การกระจายศูนย์จะเจ็บนิด ๆ ตลอดเวลา แต่ให้ความสุขก้อนใหญ่ในช่วงหายากที่ทางเลือกแบบรวมศูนย์พังลง
    • ก็แค่พูดว่ากระจายศูนย์เพราะเป็นนักพัฒนา
      ถ้าพูดภาษาคนทั่วไปก็คือ การคว่ำบาตร นั่นเอง คุณไม่พูดหรอกว่า “ขนมมันรวมศูนย์กับ Nestlé เกินไป เราต้องกระจายศูนย์ขนมกัน”
    • ฉันคิดว่าคำตอบสำหรับสิ่งที่ผู้คนต้องการจริง ๆ ไม่ใช่การกระจายศูนย์ แต่คือ ความสามารถในการย้ายออกได้

  • ฉันกำลังย้ายไป Tangled ซึ่งสร้างบน AT Protocol จึงใช้บัญชีเดียวกับ Bluesky และบริการอื่น ๆ ได้
    ลองใช้แล้วค่อนข้างชอบเลย
    https://vale.rocks/micros/20260511-0440

  • เมื่อปีก่อนฉันย้ายมา self-host Gitea ใน homelab และปิดการเข้าถึงสาธารณะไว้
    ไม่มี HTTPS ปิดการสมัครสมาชิก และ repository ก็ไม่เปิดสาธารณะ
    ตอนนี้กำลังคิดว่าจะทำ public instance และใช้ HTTPS แต่ลด attack surface ให้เหลือน้อยที่สุดอย่างไร โดยเฉพาะอยากได้คำแนะนำที่เกี่ยวกับ Gitea/Forgejo

    • ฉันทำแบบนั้นอยู่ รัน nginx กับ fail2ban บน fly.io proxy แล้วส่งต่อเข้า tailnet ของฉัน จากนั้น Caddy จะ resolve ไปยัง instance จริง
      สิ่งสำคัญคือปิด local signup ในกรณีของฉันใช้ authentik เป็น IdP ซึ่งเข้าถึงได้จากใน tailnet เท่านั้น หรือไม่ก็สร้างบัญชีของตัวเองไว้ก่อนแล้วค่อยปิดการสมัคร
      ฉันยังบล็อกบางส่วนด้วย robots.txt เช่นหน้าดู git commit ที่ render แยกทีละรายการ ไม่งั้นพวก scraper จะวนลูปไม่รู้จบ
      ฉันยังห้ามการเข้าถึง Forgejo package registry อย่างเข้มงวดด้วย เพราะมี private package อยู่ และการแยกสิทธิ์ฝั่งนั้นยังไม่ละเอียดเท่าที่อยากได้ ก็เลยยังจูนอยู่
      ฉันยังเฝ้าดูอยู่เรื่อย ๆ และจนถึงตอนนี้ยังไม่มีปัญหาใหญ่ รายละเอียดอยู่ที่ docs.eblu.me และถ้าต้องการฉันก็ลิงก์ไปยังโค้ดโครงสร้างพื้นฐานได้เลย
    • ฉันเคยทำ และตอนนี้ก็ยังรัน Forgejo instance ภายใน/LAN อยู่ แต่ตอนนี้ไม่มี public instance แล้ว
      เมื่อก่อนฉันตั้ง public read-only instance ที่ mirror จาก internal instance โดยมี reverse proxy connection เดียวจากภายในไปยัง public instance เพื่อให้ฝั่ง public ดึงข้อมูล git ไปได้
      หลังจากนั้นมันก็ทำงานเองได้ค่อนข้างดี และถ้าฉันเปลี่ยนอะไรใน Forgejo ภายใน ฝั่ง public ก็อัปเดตตาม
      issue, CI และอย่างอื่นทั้งหมดก็เก็บเป็น private อยู่ใน LAN ได้เต็มที่
    • ฉันเปลี่ยนมาใช้ Forgejo เพราะไม่ชอบดราม่าทางการเมืองรอบประเด็นช่องโหว่ความปลอดภัยที่ Forgejo อ้างว่าเคยแจ้งกับ Gitea แต่ Gitea เพิกเฉย
      เลยสงสัยว่าทำไมคุณยังใช้ Gitea อยู่ และเริ่มคิดว่าควรลองกลับไปใช้ Gitea แทน Forgejo ดีไหม