2 คะแนน โดย GN⁺ 2026-02-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการแก้ไขไฟล์ README.md เพื่อระบุอย่างชัดเจนว่าโปรเจกต์นี้ ไม่ได้รับการดูแลรักษาอีกต่อไป
  • ข้อความเดิม “maintenance mode” ถูกลบออก และแทนที่ด้วยคำเตือน “THIS REPOSITORY IS NO LONGER MAINTAINED”
  • ด้านบนของ README มีการเสนอทางเลือกทดแทน 2 แบบ คือ AIStor Free และ AIStor Enterprise
  • มีการแก้ไขข้อผิดพลาดของลิงก์ในเอกสาร และแก้ URL ของช่อง Slack ให้ถูกต้อง
  • การเปลี่ยนแปลงนี้ยืนยันว่าที่เก็บโอเพนซอร์สของ MinIO ถูกเปลี่ยนเป็นสถานะ อ่านอย่างเดียว (archive) แล้ว

การเปลี่ยนแปลงสำคัญใน README.md

  • ส่วน “Maintenance Mode” เดิมถูกลบออกทั้งหมด และแทนที่ด้วย บล็อกหมายเหตุใหม่

    • บล็อกใหม่นี้มีข้อความ “THIS REPOSITORY IS NO LONGER MAINTAINED” รวมอยู่ด้วย
    • ใต้หัวข้อ “Alternatives” มีการระบุผลิตภัณฑ์ทางเลือก 2 รายการ
      • AIStor Free: เวอร์ชันสแตนด์อโลนฟรีสำหรับชุมชน
      • AIStor Enterprise: เวอร์ชันสำหรับใช้งานแบบดีพลอยที่มีการสนับสนุนเชิงพาณิชย์รวมอยู่ด้วย
  • ลิงก์คำแนะนำการสมัครใช้งานที่เกี่ยวข้องกับ AIStor ในเอกสารเดิมถูกลบออก และสรุปใหม่เป็นคำอธิบายทางเลือกที่กระชับกว่าเดิม

การแก้ไขและจัดระเบียบอื่น ๆ

  • ลิงก์ Slack ถูกแก้จาก https//slack.min.io ที่ไม่ถูกต้อง เป็น https://slack.min.io
  • ใน ตัวอย่างตัวแปรสภาพแวดล้อม มีการแก้คำพิมพ์ผิดจาก GOARCh เป็น GOARCH
  • คำสะกดผิดใน ข้อความไลเซนส์ AGPLv3 จาก liabilites ถูกแก้เป็น liabilities
  • ในส่วน “Legacy Binary Releases” มีการเพิ่มบรรทัดว่าง 1 บรรทัดเพื่อให้อ่านง่ายขึ้น

สถานะของที่เก็บข้อมูล

  • ที่ด้านบนของหน้า GitHub แสดงข้อความว่า “This repository was archived by the owner on Feb 13, 2026. It is now read-only.
  • ซึ่งหมายความว่าที่เก็บนี้ถูก เก็บถาวร (archive) และไม่สามารถแก้ไขหรือมีส่วนร่วมเพิ่มเติมได้อีกต่อไป

ความหมาย

  • พร้อมกับการแก้ไข README ที่เก็บนี้ได้เข้าสู่สถานะ ยุติการบำรุงรักษาและถูกเก็บถาวร อย่างเป็นทางการ
  • มีการแนะนำให้เปลี่ยนจาก MinIO เวอร์ชันโอเพนซอร์สไปใช้ผลิตภัณฑ์ตระกูล AIStor Free/Enterprise แทน
  • การสนับสนุนจากชุมชนยังคงมีผ่าน GitHub และ Slack ในรูปแบบ best-effort

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

 
GN⁺ 2026-02-14
ความเห็นจาก Hacker News
  • ผมคิดว่าไม่มีปัญหาอะไรที่ MinIO จะปิดโอเพนซอร์ส
    มีคนจำนวนมากทั่วโลกที่ ใช้งานฟรีอย่างเดียว
    ผมทดสอบทางเลือกอื่นมาตั้งแต่หลายเดือนก่อน และมองว่าหลัง MinIO แล้ว RustFS จะเป็นผู้ชนะ
    ผมเปรียบเทียบ Garage, SeaweedFS, Ceph และ RustFS แล้วพบว่า RustFS กับ SeaweedFS เร็วที่สุด และการติดตั้งกับคอนโซลของ RustFS ก็สะดวกที่สุด
    Ceph ซับซ้อนเกินไปจนยากจะดีพลอยได้ถ้าไม่เข้าใจซอร์สโค้ดอย่างลึกซึ้ง
    มีเสียงวิจารณ์ว่า CLA ของ RustFS เป็น “เหยื่อล่อ” แต่ผมคิดว่ามันไม่เกินเลยในฐานะกลไกเพื่อลดความเสี่ยงทางกฎหมาย
    ที่ Milvus เองก็ประเมิน RustFS ในแง่ดี และเมื่อดูจากตัวชี้วัดทางเทคนิคแล้วผมเชื่อว่า RustFS จะชนะในท้ายที่สุด
    บทความประเมิน RustFS ของ Milvus

    • ในฐานะเมนเทนเนอร์ของ Milvus ผมอยากแชร์ความเห็นบางอย่าง
      ปัญหาผู้ใช้ฟรีมีอยู่จริง และใน ยุค AI มันยิ่งรุนแรงขึ้น
      มีผู้ใช้จำนวนมากใช้โปรเจ็กต์ฟรี แต่สัดส่วนที่เปลี่ยนมาเป็นลูกค้าแบบชำระเงินนั้นต่ำมาก
      Milvus ต้องการอ็อบเจ็กต์สตอเรจที่ดีกว่าเพื่อความเสถียรและประสิทธิภาพ และ RustFS ก็เป็นตัวเลือกที่มีแนวโน้มมาก
      แต่ในระยะยาว ถ้าอีโคซิสเต็มยังตอบโจทย์ไม่ได้ ก็อาจต้องพิจารณาสร้างเอง
      จำเป็นต้องมี การถกเถียงเรื่องความยั่งยืน ของโมเดลไลเซนส์โอเพนซอร์ส
      โมเดลแบบยุค Apache 2.0 เริ่มเห็นข้อจำกัดแล้ว และแนวทางที่แค่ “หวังว่าบริษัทต่าง ๆ จะช่วยสนับสนุน” ก็ใช้ไม่ได้อีกต่อไป
      การตัดสินใจของ MinIO จึงน่าจับตาในฐานะสัญญาณของความเปลี่ยนแปลงนี้
    • ผมรัน Ceph อยู่บนคลัสเตอร์ k8s โดยมี 4 โหนด แต่ละโหนดติดตั้ง SSD 4TB สองลูก
      ตอนตั้งค่ามันซับซ้อน แต่ตอนนี้เสถียรมาก
      Claude Code ยอดเยี่ยมมากสำหรับการดูแล Ceph และจัดการทั้งการกู้คืนหรือแก้ไข CRUSH map ได้ง่าย
      คำพูดที่ว่า “ถ้าไม่เข้าใจซอร์สโค้ดอย่างลึกซึ้งก็ deploy ไม่ได้” ผมว่าพูดเกินจริง
      ถ้า Ceph เหมาะกับงานของคุณ ผมแนะนำให้ลองจริงจัง
    • การติดตั้ง Garage ง่ายมาก
      แค่ติดตั้งไบนารีตัวเดียวแล้วเขียนไฟล์คอนฟิก /etc/garage.toml ก็พอ
      จะรันด้วย garage server หรือให้ AI ช่วยเขียน init script ให้ก็ได้
      AIStore ของ NVIDIA ก็เป็นระบบที่รองรับ S3 ได้ยอดเยี่ยม ดูได้ที่ เว็บไซต์ทางการของ AIStore
      มันเร็วกว่า MinIO แต่ประสิทธิภาพการใช้พื้นที่จะด้อยกว่านิดหน่อย
      SeaweedFS ให้ความรู้สึกเหมือนโปรเจ็กต์ส่วนตัวค่อนข้างมาก และถ้าไม่แบ็กอัปบ่อย ๆ ก็เสี่ยง
      ผมอยากหลีกเลี่ยง RustFS เพราะปัญหาเรื่อง CLA ทำให้ดูเหมือนจะเป็น การซ้ำรอยกรณี MinIO
    • SeaweedFS สร้างบนพื้นฐานของ ดีไซน์ Haystack ของ Facebook และถูกออกแบบมาสำหรับงานเฉพาะที่ต้องลดการ lookup metadata ให้น้อยที่สุด
      มันทำงานเป็นหน่วย volume และอัปเดตก็ทำในระดับ volume
      แต่อ็อบเจ็กต์สตอเรจทั่วไปมักถูกใช้เป็นแบ็กเอนด์สำหรับงานวิเคราะห์ด้วย จึงต้องการการสแกนความเร็วสูง
      เพราะฉะนั้น SeaweedFS จึงมี trade-off ที่ต่างจากอ็อบเจ็กต์สตอเรจแบบใช้งานทั่วไป
    • คุณบอกว่า CLA ของ RustFS ช่วยลดความเสี่ยงทางกฎหมาย ผมเลยอยากรู้ว่ามันลด ความเสี่ยงทางกฎหมาย แบบไหนได้บ้างโดยเฉพาะ
  • หลังจากเลิกทำบริการโอเพนซอร์สแล้ว ความเหนื่อยล้าเรื้อรัง ก็หายไป
    การทำงานฟรีมันไม่สนุก และการดูแลทั้งเวอร์ชันเสียเงินกับเวอร์ชันคอมมูนิตีพร้อมกันก็เหนื่อยมาก
    ความสัมพันธ์กับผู้ใช้ที่ไม่จ่ายเงินสุดท้ายก็กลายเป็นความเครียด
    ดูเหมือนว่าทีม MinIO ก็ได้บทเรียนแบบเดียวกัน

    • ทีม MinIO ไม่ได้ทำงานฟรี
      พวกเขาใช้โมเดล COSS (Commercial Open Source Software) คือให้เวอร์ชันพื้นฐานฟรี แล้วขายฟีเจอร์แบบเสียเงินให้ลูกค้าองค์กร
      การเปลี่ยนไปใช้ซอร์สปิดก็เป็นแค่การตัดสินใจทางธุรกิจ
      ผมใช้ SeaweedFS ในโปรดักชันมานาน และตอนนี้ก็ใช้งานร่วมกับ Wasabi อยู่
      SeaweedFS ยังยอดเยี่ยมมากสำหรับงานสตอเรจโลคัลที่ต้องการความเร็ว
    • การเก็บเงินจากผลิตภัณฑ์เป็นเรื่องปกติ แต่ผมคิดว่าการโปรโมตว่าเป็น FOSS มาตั้งแต่แรก แล้วค่อย เปลี่ยนไลเซนส์ ทีหลังนั้นมีปัญหา
      ควรบอกแผนให้ชัดตั้งแต่ต้น
      ถ้าไม่ได้ทำแบบนั้น ก็ควรรักษาคำมั่นเดิมไว้
    • ผมดูแลระบบสตอเรจโอเพนซอร์สมาหลายปีแล้ว และยังสนุกกับมันอยู่
      ตอนนี้ผมดูแล storage engine ที่ชื่อ TidesDB ต่อให้ปวดหลังก็ยังทำต่อ เพราะชอบมันจริง ๆ
    • ถ้าคุณสร้างโปรเจ็กต์โอเพนซอร์สยอดนิยมเพื่อหารายได้ นั่นแปลว่าคุณยังไม่เข้าใจ จิตวิญญาณ ของโอเพนซอร์สอย่างแท้จริง
    • ผมมีส่วนร่วมกับซอฟต์แวร์เสรีมาเกือบ 30 ปี และประสบการณ์การทำงานร่วมกับคอมมูนิติก็เติมเต็มมาก
      ประสบการณ์แบบนี้เป็นเรื่องส่วนบุคคล แต่แน่นอนว่ามันสนุกได้จริง
  • ผมย้ายจาก MinIO ไป Ceph สำเร็จแล้ว
    ผมก็ทดสอบ SeaweedFS ด้วย แต่พอวิเคราะห์บั๊กด้วยความช่วยเหลือของ Claude ก็พบว่าโครงสร้างโค้ดเละมาก
    ไม่ควรใช้ SeaweedFS กับอะไรนอกจากการทดสอบเด็ดขาด เพราะมีความเสี่ยงข้อมูลสูญหายสูง

    • SeaweedFS เป็นโปรเจ็กต์เก่า ดังนั้นสิ่งที่เห็นอาจเป็นแค่ร่องรอยของ โค้ดเบสแบบ legacy ก็ได้
    • Ceph คือ ต้นตำรับ (OG) ของอ็อบเจ็กต์สตอเรจ
      มีความพยายามทำตัวเลือกอื่นมากมาย แต่สุดท้าย Ceph ก็ยังเป็นตัวที่จัดการความซับซ้อนของปัญหานี้ได้ดีที่สุด
  • ช่วงนี้ผมกำลังย้าย MinIO ไป Ceph
    ผมสร้างคลัสเตอร์ Ceph แบบ 3 เซิร์ฟเวอร์ด้วย cephadm และกำลังทำ replication ข้อมูล 120TB ที่ความเร็ว 420MB/s
    Ceph ซับซ้อนกว่า MinIO แต่ ขยายระบบได้ดี และเสถียร
    น่าเสียดายที่คอนโซลของ MinIO หายไป
    ผมเลือก Ceph เพราะ Elasticsearch ไม่ชอบ S3 snapshot ของ Garage

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

  • มีการพูดถึง AIStore ว่าเป็นทางเลือกของ MinIO
    นอกจากนี้ยังมีตัวเลือกโอเพนซอร์สอีกหลายตัว:
    Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph

    • ผมเป็นผู้เขียน Filestash
      มันมี S3 gateway และทำ proxy การเรียก S3 ไปยัง SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive ฯลฯ
      เป็นระบบแบบ stateless อย่างสมบูรณ์ และเชื่อมต่อกับแบ็กเอนด์ได้หลากหลาย
    • RustFS มีฟีเจอร์เยอะ และสามารถทำ การจัดการคีย์ของตัวเอง ได้ด้วย แต่ยังอยู่ระหว่างการพัฒนา
      ในโค้ดก็มีการเตรียมความพร้อมสำหรับการเปลี่ยนไลเซนส์ไว้แล้ว
      Ceph เป็นตัวที่ฟีเจอร์ S3 ใกล้เคียงที่สุด แต่คอนฟิกซับซ้อนและอ่อนไหวต่อ latency
      Garage เหมาะกับการเก็บข้อมูลแบบง่าย ๆ แต่ยังขาดฟีเจอร์อย่าง ACL ขั้นสูงของ S3 หรือข้อจำกัดด้าน path
      ระบบคลัสเตอร์ของมันเป็นมิตรกับ WAN แต่ไม่จำเป็นต้องจัดวางเป็นระดับ rack แบบ Ceph
    • นอกจาก MinIO ผมเคยใช้ Garage กับ Ceph แต่สิ่งที่ต้องการคือ ระบบไฟล์ S3 แบบง่าย ๆ สำหรับทดสอบในเครื่อง
      ดูเหมือนตอนนี้ยังไม่มีทางเลือกที่ง่ายแบบนั้น
    • ผมใช้ SeaweedFS เป็นสตอเรจที่รองรับ S3 บนเครื่องเดียว
      แม้ฟีเจอร์ด้านการจัดการจะยังขาด แต่ในแง่ความถูกต้องสมบูรณ์ของข้อมูล ผมยังเชื่อใจ Ceph มากกว่า
      Ceph ให้ความรู้สึกว่าเป็นผลงานของคนที่เข้าใจระบบกระจายอย่างลึกซึ้งจริง ๆ
    • ผมเพิ่มรายชื่อทางเลือกด้านบนเข้าไปในรีโพ MinIO ผ่าน Pull Request แล้ว
      ลิงก์ PR
  • ถ้าดู เธรด HN ก่อนหน้า จะเห็นได้ว่า MinIO เข้าสู่โหมด maintenance ไปแล้วก่อนหน้านี้
    ตั้งแต่ตอนนั้นก็นับว่าเป็นการส่งสัญญาณล่วงหน้าถึงการเปลี่ยนไปเป็นซอร์สปิด

    • แต่โหมด maintenance กับ “ไม่บำรุงรักษาอีกแล้ว” ไม่เหมือนกัน
  • MinIO ขาดความโปร่งใสมาตั้งแต่ก่อนแล้ว และห่างไกลจากจิตวิญญาณโอเพนซอร์ส ทั้งการ ลบ issue ที่วิจารณ์ หรือการล็อกคอมเมนต์
    เพราะแบบนั้นทันทีที่มันเข้าสู่โหมด maintenance ผมก็ย้ายไป Garage
    ผมกำลังเตรียม PR อยู่ แต่ยังไม่ได้ส่ง

    • โปรเจ็กต์แบบนี้ต้องใช้ทักษะขั้นสูง ดังนั้นผมคิดว่าไม่มีเหตุผลที่จะต้องรองรับ ผู้ใช้ฟรี
      โอเพนซอร์สจริงจังส่วนใหญ่ได้รับการสนับสนุนจากภาคอุตสาหกรรม และยากที่นักพัฒนาเว็บทั่วไปจะมีส่วนร่วมได้
  • ผมแนะนำให้ ฟอร์กเก็บไว้ในเครื่อง เผื่อกรณีที่รีโพ MinIO ถูกลบ
    รีโพสาธารณะบน GitHub ถ้าถูกลบ ฟอร์กยังคงอยู่ แต่ถ้าเปลี่ยนเป็น private ฟอร์กจะหายไปด้วย
    เคยมีเหตุการณ์คล้ายกันกับ Gem ชื่อ prawn_plus ในอีโคซิสเต็ม Ruby
    ดู เอกสารนโยบายฟอร์กของ GitHub
    สำหรับคนที่ใช้ MinIO แค่เพื่อทดสอบในเครื่อง มันอาจกลายเป็น กับดักที่ค่อย ๆ ปิดลง

  • หากคุณกำลังใช้งานโซลูชันด้าน Observability ที่ต้องพึ่งอ็อบเจ็กต์สตอเรจ เช่น Thanos, Loki, Mimir, Tempo
    ลองพิจารณา VictoriaMetrics, VictoriaLogs, VictoriaTraces แทนได้
    พวกมันใช้บล็อกสตอเรจเป็นฐาน ขยายได้ถึงระดับเพตะไบต์ และให้ทั้งประสิทธิภาพกับความพร้อมใช้งานสูงโดยไม่ต้องดูแลจัดการด้วยตนเองมากนัก