การย้ายโครงการ Dillo จาก GitHub

 (dillo-browser.org)
2 คะแนน โดย GN⁺ 2025-12-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์เว็บเบราว์เซอร์ Dillo กำลังดำเนินการ ย้ายจาก GitHub ไปยังเซิร์ฟเวอร์ที่โฮสต์ด้วยตนเอง
  • เหตุผลหลักในการย้ายได้แก่ การพึ่งพา JavaScript, โครงสร้างการควบคุมแบบรวมศูนย์ และความช้าในการทำงาน ของ GitHub
  • เซิร์ฟเวอร์ใหม่ใช้งานบนโดเมน dillo-browser.org โดยใช้ Git frontend ขนาดเบาที่สร้างจาก cgit และระบบติดตามบั๊กที่พัฒนาขึ้นเองชื่อ “buggy”
  • ข้อมูลทั้งหมดถูกจัดการเป็น ที่เก็บ git และทำการ mirror ไปยัง Codeberg และ Sourcehut เพื่อ ลดความเสี่ยงการสูญหายข้อมูลให้น้อยที่สุด
  • โครงสร้างนี้ถูกออกแบบด้วย ลายเซ็น OpenPGP เพื่อยังคงความน่าเชื่อถือได้แม้กรณี DNS สูญหาย และเสริม ความเป็นอิสระและความยั่งยืนของโครงการ

ภาพรวม

  • เว็บไซต์ต้นฉบับของ Dillo คือ dillo.org ซึ่งประกอบด้วยที่เก็บ Mercurial, เซิร์ฟเวอร์อีเมล, ระบบติดตามบั๊ก และคลังเก็บ mailing list
    • ในปี 2022 โดเมนเดิมหายไป และมีบุคคลที่สามตั้งเว็บไซต์เลียนแบบที่เต็มไปด้วยโฆษณา AI
    • ข้อมูลบางส่วนถูกกู้คืนแล้ว แต่ยังไม่สมบูรณ์
  • จากประสบการณ์ดังกล่าว ทีมตัดสินใจเลี่ยงการพึ่งพาเว็บไซต์เพียงแห่งเดียว และสร้างโครงสร้างสำรองแบบกระจาย
  • ตอนแรกได้อัปโหลดโค้ดขึ้น GitHub แต่ต่อมาเห็นว่าไม่เหมาะสมในระยะยาว

ข้อจำกัดของ GitHub

  • GitHub มีประโยชน์สำหรับ workflow CI และการจัดการที่เก็บโค้ด แต่ยังมี ข้อจำกัดหลายด้าน
    • หน้าแสดงผลด้านหน้าไม่ทำงานหากไม่มี JavaScript ทำให้ไม่สามารถดู Issue หรือ PR ด้วยเบราว์เซอร์ Dillo ได้
    • หน้าเว็บใช้ ทรัพยากรมากเกินไป และเกิดภาระส่วนเกินแม้เป็นการเรนเดอร์ HTML แบบธรรมดา
  • มีความเสี่ยงที่บัญชีจะถูกบล็อกจาก เจ้าของการควบคุมจุดเดียว ทำให้การเข้าถึงข้อมูลถูกตัดขาดได้
  • แพลตฟอร์มค่อยๆ ช้าลง และต้องการการเชื่อมต่ออินเทอร์เน็ตที่เร็วขึ้น
  • วิธีแจ้งเตือนแบบ “push model” ของ GitHub ไม่เหมาะกับแนวทางการพัฒนาที่เน้นการทำงานแบบออฟไลน์
  • ขาดเครื่องมือจัดการชุมชนในโครงการที่มีผู้ใช้ไม่ใช่นักพัฒนาเป็นสัดส่วนสูง ทำให้เหนื่อยล้าของนักพัฒนาสูงขึ้น
  • เมื่อ GitHub หันมาเน้น LLM และ Generative AI มากขึ้น เว็บไซต์ต่างๆ จึงเสริมการป้องกัน LLM crawler โดยเพิ่ม JavaScript wall หรือติดตาม browser fingerprinting
    • ส่งผลให้เกิดผลข้างเคียงคือผู้ใช้ Dillo ถูกปิดกั้นการเข้าถึง

การตั้งระบบโฮสต์เอง

  • บริการเก็บโค้ดที่มีอยู่ไม่สามารถตอบโจทย์ทั้งการขจัดจุดล้มเหลวเดียวและการรันระบบที่ประหยัดน้ำหนักพร้อมกันได้
    • ดังนั้นจึงตัดสินใจ รันเซิร์ฟเวอร์เองและรักษา mirror หลายแห่ง
  • ซื้อโดเมน dillo-browser.org และสร้าง เซิร์ฟเวอร์ VPS ขนาดเล็ก
    • ระบบกำลังทำงานได้เสถียรกว่าที่คาดหวัง และรับภาระทราฟฟิกจาก AI bots เป็นหลัก
  • เลือกใช้ cgit เป็น Git frontend
    • พัฒนาในภาษา C จึงใช้ RAM และ CPU ต่ำ และทำงานได้ โดยไม่ต้องใช้ JavaScript
    • ปรับ CSS บางส่วนเพื่อให้ดูดีบน Dillo
    • เข้าถึงได้ที่ https://git.dillo-browser.org/
  • ใช้ระบบติดตามบั๊กที่พัฒนาขึ้นเองชื่อ ‘buggy’
    • แยกวิเคราะห์ไฟล์ Markdown เพื่อสร้างหน้า HTML และเก็บบั๊กแต่ละรายการไว้ใน ที่เก็บ git
    • เมื่อมีการ commit git hook จะอัปเดตหน้าต่าง ๆ โดยอัตโนมัติ
    • รองรับการแก้ไขแบบออฟไลน์ และไม่ก่อให้เกิดความเสี่ยงด้านความปลอดภัย
    • ดูได้ที่ https://bug.dillo-browser.org/
  • อาร์ไคฟ์ mailing list ถูกกระจายเก็บบน บริการภายนอก 3 แห่ง และมีแผนเพิ่มสำเนาของตัวเองในอนาคต

การกำหนดค่า mirror

  • ข้อมูลสำคัญทั้งหมดถูกจัดการในรูปแบบ ที่เก็บ git และทำ mirror ไปยัง Codeberg และ Sourcehut
    • หากที่เก็บโค้ดใดที่หนึ่งหยุดให้บริการก็สามารถย้ายไปยัง mirror อื่นได้ด้วย ต้นทุนการย้ายที่ต่ำ
  • จุดล้มเหลวเดียวที่เหลือคือ DNS (dillo-browser.org)
    • หากสูญเสีย DNS ได้ มีช่องทางแจ้งผู้ใช้ผ่าน mailing list, Fediverse, IRC และอื่นๆ
    • ข้อมูลถูกคัดลอกใน git จึง ไม่เกิดการสูญเสียรุนแรง

ลายเซ็น OpenPGP

  • หน้าปัจจุบันถูกเซ็นด้วย คีย์ GPG ของ Rodrigo Arias Mallo (32E65EC501A1B6FDF8190D293EE6BA977EB2A253)
    • เป็นคีย์เดียวกับ release ล่าสุดของ Dillo และลงทะเบียนในบัญชี GitHub แล้ว
    • ไฟล์ลายเซ็น (index.html.asc) ถูกเชื่อมผ่าน <link rel=signature>
  • ลายเซ็น OpenPGP ทำให้ความน่าเชื่อถือยังคงอยู่แม้ DNS จะหาย
    • แทนการพิสูจน์สิทธิ์ผ่าน ห่วงโซ่ใบรับรอง TLS ด้วยการยืนยันผ่าน ความเชื่อถือจากลายเซ็น
    • ใส่ลายเซ็นในทุก git mirror เพื่อเพิ่ม ความทนทานต่อการสูญเสียข้อมูล

ความคืบหน้าและอนาคตของการย้าย

  • ที่เก็บของ GitHub ไม่ถูกลบทันที และจะยังคงอัปเดตต่อเนื่องจนกว่าย้ายเสร็จสมบูรณ์
    • เมื่อเสร็จแล้วจะเปลี่ยนสถานะที่เก็บเป็น ‘archived’ และแจ้งบนเว็บไซต์ทางการ
    • คอมมิตต์และไฟล์ release เดิมถูกเก็บไว้เพื่อ ความเข้ากันได้ของ build ย้อนหลัง
  • โครงสร้างพื้นฐานใหม่สามารถดำเนินการได้แบบอิสระด้วย ต้นทุนและการใช้พลังงานที่ต่ำ
    • โดยอิงจากเงินบริจาคและค่าใช้จ่ายเซิร์ฟเวอร์ปัจจุบัน คาดว่าจะคงไว้ได้อย่างน้อย 3 ปี
    • หากต้องการสนับสนุน สามารถสนับสนุนผ่าน Liberapay (https://liberapay.com/dillo/)

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

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

 
GN⁺ 2025-12-01
ความคิดเห็นบน Hacker News

  • ตลอดหลายปีที่ผ่านมาใช้ GitLab เป็นทางเลือกแบบ self-hosted มาตลอด ชอบนะ แต่กินทรัพยากรหนัก
    ช่วงนี้กำลังทดสอบ Forgejo ที่ทีม Codeberg ทำขึ้นมา แล้วมันยอดเยี่ยมมาก
    ความต่างที่ใหญ่ที่สุดคือการใช้หน่วยความจำ GitLab สร้างบน Ruby on Rails เลยมีหลาย service รันพร้อมกัน แต่ Forgejo เป็นโครงสร้างแบบ single binary ที่เขียนด้วย Go
    GitLab ค่อย ๆ กินหน่วยความจำของ VM 16GB จนหมด แต่ Forgejo ใช้แค่ราว 300MB แม้จะรันทั้ง server และ runner พร้อมกัน
    ไม่มี GraphQL แต่ REST API ก็ดูดีเพียงพอ
    ยังไม่ค่อยเข้าใจความต่างระหว่าง gitea กับ forgejo แต่ดูจากเอกสารเปรียบเทียบของ Forgejo เหมือนว่าจะเป็น soft fork ที่เกิดจากปัญหาเรื่อง governance ในปี 2022

    • สตูดิโอของเรามีผู้ใช้ราว 50 คนที่ใช้ git ทุกวัน และย้ายมา Forgejo ทั้งหมดเมื่อ 2 ปีก่อน
      ด้วยความที่เป็นโครงสร้างเรียบง่ายบน Go เลยดูแลง่ายและต้นทุนต่ำมาก เรายังสร้างเครื่องมือภายในบน Forgejo โดยตรงด้วย
      เพราะโฮสต์แบบ on-premises ต่อให้อินเทอร์เน็ตล่ม งานพัฒนาและ CI ก็ไม่หยุด รองรับ package manager cache ด้วยเลยจัดการ dependency ได้ง่าย
    • ถ้าพูดถึงความสะดวกในการดูแลรักษา gitea กินขาด ใช้มานานกว่า 5 ปีแล้ว การอัปเกรดจบแค่ pull เวอร์ชันใหม่แล้วรีสตาร์ต daemon
      มันมีdowntime น้อยกว่า GitHub 10 เท่า และส่วนใหญ่ก็เป็นการบำรุงรักษาตามแผน
      เวลาเห็นคนเขียนว่า GitHub มี availability ดีกว่าแล้วก็อดขำไม่ได้
    • ถ้าเป็นโปรเจกต์ส่วนตัว ผมคิดว่าแค่มี SSH server กับ file system ก็พอแล้ว
      ตอนสร้าง repository ใหม่ก็จบด้วย git init --bare
      backup ก็ทำงานอัตโนมัติอยู่แล้ว
      ถ้าพัฒนาคนเดียวก็รู้สึกว่าไม่ได้จำเป็นต้องมี UI
    • ดูจากเอกสารแนวคิดพื้นฐานของ Forgejo Actions แล้ว ระบบ CI จัดไว้ดีมาก
      ผมคิดว่า CI แบบ GitLab ดีกว่า GitHub Actions มาก GitHub กลายเป็นมาตรฐานเพราะความนิยม แต่การออกแบบยังน่าเสียดาย
    • ถ้าอยากได้ทางเลือกที่มินิมัลกว่านี้ก็มี Gerrit ด้วย เป็นแอป Java ที่ไม่ต้องพึ่ง DB ภายนอก และเก็บทั้งการตั้งค่าและข้อมูล runtime ไว้ใน git repo
      แค่มี shared filesystem ก็ขยายระบบและทำ backup ได้ง่าย

  • ผมดูแลชมรมคณิตศาสตร์ในท้องถิ่น และใช้ Forgejo ให้เด็ก ๆ ส่งการบ้าน LaTeX และ Python
    มันจัดการล็อกอินและรีเซ็ตรหัสผ่านง่าย เลยมีประโยชน์มากสำหรับงานด้านการศึกษา

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

    • ถ้ายังไม่พอใจก็ใช้ฟังก์ชันแจ้งเตือนใน UI ของ GitHub เองได้ จริง ๆ รู้สึกเหมือนเป็นการหาปัญหาให้ตัวเองมากกว่า

  • เรื่องของคนที่สร้าง**bug tracker ง่าย ๆ ชื่อ ‘buggy’**ขึ้นมาเองน่าสนใจดี เขาบอกว่าเป็นเครื่องมือ C ที่ parse Markdown แล้วสร้างหน้า HTML
    จิตวิญญาณแฮ็กเกอร์ยังมีชีวิตอยู่

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

  • มีคนถามถึงความต่างระหว่าง “โมเดล push” กับ “โมเดล pull”

    • น่าจะหมายถึงworkflow แบบใช้อีเมลเป็นฐานอย่าง Source Hut หรือ Linux kernel ใช้ IMAP ดึง patch มาไว้ในเครื่องได้ และทำงานออฟไลน์ต่อได้
    • แบบ push จะมีแรงกดดันเรื่องเวลาในทำนองว่า ‘ทำเดี๋ยวนี้เลย’ ส่วนแบบ pull คือวิธีจัดการเวลาที่เราเลือกเช็กตามรอบของตัวเอง

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

    • กระแสแบบนี้มีมาตั้งแต่ 10 ปีก่อนแล้ว สมัยก่อนเป็นช่วงที่คนย้ายไป GitLab และตอนนี้เรื่องdiscoverabilityของ GitHub ก็ยังไม่มีใครเทียบได้
      โปรเจกต์ที่ย้ายออกจาก GitHub ยังมีน้อยมาก ผมเลยคิดว่ายังเร็วเกินไป
    • นักพัฒนาแต่ละคนมีวิธีร่วมงานกันต่างกัน เลยยากที่จะไปลงเอยที่โซลูชันเดียว
      ตรงกันข้าม ตอนนี้กำลังเกิดre-decentralizationมากกว่า เป็นยุคที่แต่ละคนเลือก forge ให้เหมาะกับการควบคุม เขตอำนาจ และ workflow ของตัวเอง
    • เป้าหมายต่อไปคือการไปสู่โครงสร้างแบบfederation ไม่ใช่ศูนย์กลางแบบ GitHub เพื่อไม่ต้องพึ่งพาเอนทิตีเดียว
    • ประเด็นสำคัญคือ เราต้องการ ‘ตัวแทนเดียว’ หรืออยากกลับมาเจอสถานการณ์แบบเดิมอีกในอีก 5 ปี
    • เรากำลังพยายามทำสิ่งนั้นอยู่พอดี กำลังเตรียมแพลตฟอร์มร่วมงานสายอินดี้ชื่อ Tangled และจะมีประกาศใหญ่เร็ว ๆ นี้

  • อยากชวนโปรเจกต์ Dillo มาที่ Tangled → tangled.org

    • ประทับใจที่มันทำงานได้ดีแม้ไม่มี JavaScript
    • อยากให้รองรับระบบควบคุมเวอร์ชันอื่นนอกจาก Git ด้วย

  • ผมคิดว่าปัญหาใหญ่สุดคือประสบการณ์ใช้งานของ GitHub ที่ช้าลง

    • สงสัยว่าวลี “more and more slow” ฟังเป็นธรรมชาติไหม หรือ “slower and slower” จะปกติกว่า?
    • เมื่อก่อนก็โอเค แต่ช่วงหลังโหลดหน้าเว็บช้ามาก ไม่น่าใช่แค่เพราะ React อย่างเดียว
      เรื่องดูโค้ดแก้ด้วย github.dev ได้ แต่ PR กับ Actions ยังช้าและอืดมาก

  • ถ้าอยากติดตั้ง Forgejo บน VM ผมทำสคริปต์ไว้ให้เซ็ตทั้ง server และ runner ได้ในทีเดียว → easyforgejo

  • ผมไม่ได้เชี่ยวชาญเรื่องนี้ แต่ก็อ่านอย่างสนใจ
    น่าแปลกใจที่แค่การตั้งระบบควบคุมเวอร์ชันตัวหนึ่งกลับมีองค์ประกอบให้คิดเยอะขนาดนี้
    ผมใช้ Fossil อยู่ และสำหรับองค์กรเล็ก ๆ ที่คนเดียวต้องเป็นทั้งนักพัฒนา ผู้ดูแลระบบ และฝ่ายซัพพอร์ต มันง่ายกว่ามาก
    ข้อจำกัดของ deploy key บน GitHub ก็ทำให้ลำบากเหมือนกัน เวลาต้องดูแลหลายแอปและหลายเซิร์ฟเวอร์ ต้องตั้งคีย์แยกกันทีละตัว มันยุ่งยาก