การลบ docker.io/Bitnami

• ทีม Bitnami เลื่อนกำหนดเวลาลบแค็ตตาล็อกสาธารณะ docker.io/bitnami ไปเป็นวันที่ 29 กันยายน
• ก่อนลบจะมีการทำ brownout (บล็อกอิมเมจบางส่วนชั่วคราว) หลายครั้ง เพื่อช่วยให้ผู้ใช้ปรับตัวได้
• จากนี้ไป คอนเทนเนอร์อิมเมจและ Helm chart ของ Bitnami จะย้ายไปอยู่ที่ Bitnami Secure Images (BSI) ซึ่งมีฟีเจอร์ความปลอดภัยที่แข็งแกร่ง หรือ Bitnami Legacy Registry
• อิมเมจ BSI เปิดให้ใช้ฟรีสำหรับงานพัฒนาและทดสอบ แต่หากต้องการใช้อิมเมจทั้งหมดและการสนับสนุนระยะยาว จะต้องมี การสมัครใช้งานแบบเสียเงิน
• เนื่องจากต้องรับมือกับความปลอดภัยของซัพพลายเชนโอเพนซอร์สและการเปลี่ยนแปลงด้านกฎระเบียบ จึงจำเป็นต้องเปลี่ยนผ่านจากแนวทางเดิม

---

กำหนดการลบแค็ตตาล็อกสาธารณะ docker.io ของ Bitnami และแนวทางรับมือ

อัปเดต

• ทีม Bitnami หลังจากรับฟัง ความเห็นจากชุมชนและประเมินผลกระทบ แล้ว ได้เลื่อนกำหนดเวลาลบแค็ตตาล็อกสาธารณะ docker.io/bitnami ไปเป็นวันที่ 29 กันยายน 2024
• ก่อนลบรีจิสทรี จะมีการทำ brownout (ปิดกั้นคอนเทนเนอร์อิมเมจบางส่วนชั่วคราวเป็นเวลา 24 ชั่วโมง) จำนวน 3 ครั้ง เพื่อให้ผู้ใช้รับรู้การเปลี่ยนแปลง
  • 28 สิงหาคม 08:00 UTC ~ 29 สิงหาคม 08:00 UTC
  • 2 กันยายน 08:00 UTC ~ 3 กันยายน 08:00 UTC
  • 17 กันยายน 08:00 UTC ~ 18 กันยายน 08:00 UTC
• ในแต่ละ brownout จะประกาศอิมเมจที่ได้รับผลกระทบในวันนั้น
• ตั้งแต่วันที่ 28 สิงหาคม จะไม่มีการเผยแพร่คอนเทนเนอร์อิมเมจและ Helm chart ของ Bitnami ไปยัง Docker Hub ในรูปแบบใหม่ (OCI) อีกต่อไป
• ซอร์สโค้ดของคอนเทนเนอร์และ Helm chart จะยังคงเผยแพร่บน GitHub ต่อไปภายใต้ไลเซนส์ Apache 2.0

สิ่งที่จะเปลี่ยนแปลง

• ตั้งแต่วันที่ 28 สิงหาคม Bitnami จะย้าย OCI registry เดิม (chart และอิมเมจ) ไปยัง Bitnami Legacy และหลังจากนั้นจะเปลี่ยนไปใช้อิมเมจใหม่ที่เสริมความปลอดภัยมากขึ้น

• หากใช้อิมเมจปัจจุบันอยู่ จะต้องเปลี่ยน เส้นทางการ pull อิมเมจ ของ automation pipeline, internal mirror และ Kubernetes cluster ไปยังตำแหน่งใหม่

• ตัวเลือกที่ผู้ใช้สามารถเลือกได้

  1. เปลี่ยนไปใช้ Bitnami Secure Images (BSI)
  2. เปลี่ยนไปใช้ Bitnami Legacy Registry (ชั่วคราว)

• เพื่อความต่อเนื่องของระบบและการคงไว้ซึ่งฟังก์ชันการทำงาน แนะนำให้เปลี่ยนไปใช้ Bitnami Secure Images (BSI)

• การใช้ BSI มีข้อดีคือช่วยเพิ่มความสามารถในการรับมือด้านความปลอดภัยและคอมพลายแอนซ์ผ่าน อิมเมจที่เสริมความแข็งแกร่ง

การย้ายไปใช้ Bitnami Secure Images (BSI)

• อิมเมจ BSI บางส่วนเปิดให้ใช้ฟรีสำหรับงานพัฒนาและทดสอบ แต่แค็ตตาล็อกทั้งหมด, stable tag และเวอร์ชันที่รองรับระยะยาวนั้น ใช้งานได้เมื่อสมัครแบบเสียเงิน
• ผู้สมัครใช้ BSI จะยังคงได้รับ แค็ตตาล็อกอิมเมจทั้งหมดของ Bitnami ที่อิง Debian และการอัปเดตต่อไป
• แนะนำให้อัปเกรดและย้ายไปใช้อิมเมจ ที่อิง Photon Linux ซึ่งเสริมความแข็งแกร่งยิ่งขึ้น
  • เข้ากันได้กับอิมเมจ Debian เดิม และยังใช้ Helm chart เดิมได้เหมือนกัน
• ข้อดีหลักของอิมเมจที่อิง Photon
  • จำนวน CVE ลดลงอย่างมาก (จาก 100+ เหลือ 0 ได้ในบางกรณี)
  • รองรับ การวินิจฉัย VEX และเชื่อมโยงคะแนน KEV/EPSS ทำให้จัดการช่องโหว่ได้ง่ายขึ้น
  • มี UI/API แบบ self-service สำหรับการรายงานและเมทาดาทาที่ทรงพลัง
  • รองรับ Helm chart ขั้นสูง เช่น distroless chart ที่ ลด attack surface ได้ 83%
  • สามารถปรับแต่งอิมเมจที่บิลด์จาก software factory ที่ สอดคล้องกับ SLSA 3 (มาตรฐานความปลอดภัยซัพพลายเชน)
  • มี private security OCI registry เฉพาะลูกค้า ให้ใช้ (ไม่ติดข้อจำกัดแบบ public/rate limit เหมือน Docker Hub)
  • ใช้งาน VM image รูปแบบ OVA ได้มากกว่า 90 ชนิด
  • มีการสนับสนุนระดับองค์กรด้านแพ็กเกจและการติดตั้ง

การย้ายไปใช้ Bitnami Legacy Registry

• ในฐานะทางออกชั่วคราว Bitnami เปิดให้ผู้ใช้เดิมใช้งาน Bitnami Legacy Registry
  • เป็นอิมเมจในรูปแบบ archive ที่ไม่ได้รับการสนับสนุน (เช่น ไม่มี security patch)
  • ไม่มีแผนให้บริการระยะยาว: มีความเสี่ยงที่ ช่องโหว่จะสะสมและล้าสมัยอย่างรวดเร็ว
  • หากจะใช้ชั่วคราว แนะนำให้คัดลอกอิมเมจที่จำเป็นไปเก็บไว้ใน รีจิสทรีของตนเอง แยกต่างหาก
  • ในระยะยาวยังจำเป็นต้องย้ายไปสู่ระบบใหม่ที่เสริมความปลอดภัย (BSI) ให้เร็วที่สุด

เหตุผลที่ต้องเปลี่ยนผ่านด้านความปลอดภัยของซัพพลายเชนโอเพนซอร์สและคอมพลายแอนซ์

• ปัจจัยสำคัญคือการเปลี่ยนแปลงล่าสุดของระบบนิเวศโอเพนซอร์สและ การเพิ่มขึ้นอย่างมากของแพ็กเกจอันตราย (ตาม Sonatype ในช่วง 2019~2023 มีมากกว่า 245,000 รายการ)
  • คิดเป็นประมาณ 2 เท่าของทุกช่วงเวลาก่อนหน้านั้นรวมกัน
• การเติบโตของระบบนิเวศ AI/โมเดลทำให้การใช้งานโอเพนซอร์สเพิ่มขึ้นอย่างมาก → attack surface และความเสี่ยงก็เพิ่มขึ้นด้วย
• กฎระเบียบอย่าง Cyber Resilience Act (EU) กำลังทำให้เกิด ภาระในการพิสูจน์แหล่งที่มาและความถูกต้องสมบูรณ์ ของซอฟต์แวร์โอเพนซอร์ส
• การนำ Bitnami Secure Images มาใช้ จะช่วยให้องค์กรมีสภาพแวดล้อมที่ทำ ความปลอดภัยของซัพพลายเชนและคอมพลายแอนซ์ ได้ง่ายขึ้น
  • ลดภาระต้นทุนด้านความปลอดภัยและกฎระเบียบด้วย TCO (ต้นทุนรวมของการเป็นเจ้าของ) ที่ต่ำ
  • วางรากฐานสำหรับการจัดการสภาพแวดล้อมซอฟต์แวร์โอเพนซอร์สที่ซับซ้อนขึ้นอย่างมั่นคง

ข้ออ้างของคู่แข่งเกี่ยวกับการเปลี่ยนแปลงของ Bitnami

• คู่แข่งบางรายทำให้เกิดความเข้าใจผิดว่า Bitnami กำลัง "ยกเลิกอิมเมจสาธารณะฟรีและ Helm chart"
  • ในความเป็นจริง Helm chart ยังคง เปิดเผยบน GitHub ต่อไปภายใต้ ไลเซนส์ Apache 2
  • แก่นของการเปลี่ยนแปลงอยู่ที่ OCI artifact (อิมเมจที่บิลด์แล้ว)
  • ต้นทุนของ pipeline สำหรับการบิลด์และแจกจ่ายในระดับใหญ่ รวมถึงการดำเนินงานรีจิสทรีนั้นสูงมาก และไม่สามารถให้บริการด้วยต้นทุนต่ำได้
  • ซอร์สของ Helm chart (รวมถึงอิมเมจ Debian) ยังเข้าถึงได้ฟรีสำหรับทุกคน
• หากองค์กรต้องการ OCI build image โดยตรง จะต้องรับการสนับสนุนผ่าน การสมัคร BSI ซึ่งเป็นวิธีในการยกระดับความปลอดภัยและใช้ OSS เชิงกลยุทธ์ได้อย่างมั่นคง

วิธีการเปลี่ยนผ่านอย่างเป็นรูปธรรมหลังวันที่ 28 สิงหาคม

• ตั้งแต่วันที่ 28 สิงหาคม Bitnami repo จะเริ่ม จัดระเบียบอิมเมจเป็นลำดับขั้น โดยการเปลี่ยนผ่านทั้งหมดจะไม่เกิดขึ้นพร้อมกันในครั้งเดียว
• จะค่อย ๆ ลบ/ย้ายอิมเมจตลอดหลายสัปดาห์ → เป็นมาตรการเพื่อลดความสับสนของผู้ใช้ให้น้อยที่สุด
  • เนื่องจากต้องจัดการ OCI content ปริมาณมหาศาลถึง 84TB จึง ยังไม่ชัดเจนว่าอิมเมจใดจะถูกลบเมื่อใด
  • ตั้งแต่วันที่ 28 สิงหาคม เป็นต้นไป อิมเมจที่จำเป็นต่อฟังก์ชันธุรกิจหลักควร เตรียมรีจิสทรีทางเลือก ไว้
• ใน รีจิสทรีใหม่ของ Bitnami จะอัปโหลดอิมเมจ Photon ที่เสริมความแข็งแกร่งภายใต้ ชื่อเดียวกัน กับอิมเมจ Debian เดิม
• ผู้ใช้เดิมและผู้ใช้ใหม่จะสามารถรับมือกับความต้องการล่าสุดของสภาพแวดล้อมโอเพนซอร์สได้ผ่านอิมเมจที่เสริมความปลอดภัย
• ดูรายละเอียดเพิ่มเติมเกี่ยวกับการเปลี่ยนผ่านได้ที่ Bitnami FAQ

[jic5760]

เพื่อสานต่อ Bitnami ในคอมมูนิตี้ เมื่อวานนี้ผมจึงสร้าง Bitmoa ขึ้นมา
เป้าหมายคือแทนที่อิมเมจของ bitnami ด้วยการเปลี่ยนแปลงให้น้อยที่สุด (ประมาณ ENV)

https://github.com/bitmoa/containers (ใช้ GH action ในการบิลด์อิมเมจ)
https://github.com/bitmoa/charts

[GN⁺]

ความคิดเห็นบน Hacker News

• ค่อนข้างน่าแปลกใจที่แค่เอาซอฟต์แวร์โอเพนซอร์สมาทำ "แพ็กเกจจิง" โดยแทบไม่ได้มีส่วนร่วม แล้วจะคิดเปลี่ยนไปเป็นเชิงพาณิชย์แบบสไตล์ Oracle แต่ก็ไม่ได้ตั้งใจจะลดคุณค่าของงานพวกเขา แค่สงสัยว่าส่วนที่พอจะอ้างลิขสิทธิ์ได้จริงมีมากแค่ไหน ส่วนใหญ่แต่ละแพ็กเกจก็เหมือนแค่สูตรประกอบไม่กี่บรรทัด ราวกับพยายามจะถือลิขสิทธิ์กับบรรทัดคำสั่งอย่าง make build และถ้าใบอนุญาตโอเพนซอร์สครอบคลุมไบนารีที่สร้างเสร็จแล้ว ผู้ใช้ก็ควรได้ทั้งซอร์สโค้ด วิธีบิลด์ และสิทธิ์ในการแจกจ่ายต่อ
  • ส่วนที่ Bitnami ทำอย่าง Makefile เองก็มีงานที่ลงแรงพอสมควร และการทำให้ซอฟต์แวร์หลากหลายชนิดใช้งานได้ผ่านแค่ environment variables นั้นไม่ใช่เรื่องง่ายเลย ดู ตัวอย่าง ได้ และสำหรับผู้ใช้บางกลุ่มตอนนี้ไลเซนส์เชิงพาณิชย์ก็มีคุณค่ามากพอ
  • จริง ๆ แล้วคุณค่าที่สำคัญกว่าน่าจะเป็น Helm charts แต่เพราะมี official images ออกมาเป็นตัวแทนอยู่แล้ว จึงไม่มีเหตุผลชัดเจนว่าทำไมต้องใช้ image ของ Bitnami สำหรับ Node หรือ Postgres โดยเฉพาะ เลยสงสัยว่าจริง ๆ แล้วมีคนใช้ Helm charts ของ Bitnami มากแค่ไหน
• hardened images ที่ Bitnami เคยให้มาถือเป็นสัญลักษณ์ของ goodwill และช่วยให้คนเริ่มต้นในจุดที่ต้องการได้จริง แต่ในตลาดมันสู้ตัวเลือกที่ดีกว่าไม่ได้ การเปลี่ยนไปเป็น "subscription" แบบนี้ไม่ใช่ทางแก้ แต่เหมือนการยัดเยียดมากกว่า คล้ายกับที่ Terraform Cloud เคยทำ และฝั่งนั้นทุกวันนี้ก็ดูสถานการณ์ไม่ดีเหมือนกัน ผลงานของ Bitnami เองก็แทบมีแค่เพิ่มตัวเลือก config นิดหน่อย ถ้าเทียบกับ OperatorFramework capability ก็คงอยู่แค่ประมาณ level 2 หรือ 1 ลิงก์อ้างอิง
  • มองว่าการเรียกสถานการณ์ที่ Bitnami เคยให้ฟรีแล้วตอนนี้เลิกให้ จนผู้ใช้ต้องไปหาของแทนว่าเป็นการ "ยัดเยียด" นั้นเกินไปหน่อย แค่ที่เคยให้ฟรีมาก่อนก็น่าขอบคุณแล้ว
  • การบอกว่าเลิกให้ของฟรีคือการยัดเยียดนี่เป็นคำพูดที่แรงเกินไป สิ่งที่เหลืออยู่ก็แค่ความเสียดายที่จากนี้ต้องทำเอง
  • เหมือนมีความสับสนว่า Broadcom เป็นบริษัทแบบไหน Broadcom ไม่ได้สนใจ "สุขภาพระยะยาว" ของอะไรเลย พอซื้อผลิตภัณฑ์มาก็ปลดพนักงาน 90% แล้วขึ้นค่าลิขสิทธิ์กับค่าซัพพอร์ต 2–100 เท่า อาศัยข้อเท็จจริงที่บริษัท Fortune 500 ถอนตัวออกได้ยาก แล้วรีดรายได้ด้วยสัญญาระยะประมาณ 5 ปี ต่อให้ตลาดต่อต้านก็ไม่ค่อยสนใจ และแม้ต้องสู้กันทางกฎหมาย สุดท้ายผลของการขึ้นราคาก็ยังอยู่
  • ในปี 2025 กลยุทธ์แบบบริษัทอินฟราที่สร้างความนิยมในหมู่นักพัฒนาก่อนแล้วค่อยเปลี่ยนเป็นรายได้นั้นใช้ไม่ได้แล้ว ต้องสร้างรายได้ตั้งแต่แรก และสุดท้ายก็มีเป้าหมายแค่ตลาดเอ็นเตอร์ไพรส์ ทุกคนเลยต้องแย่งกันในตลาดแคบ ๆ นี้
  • มูลค่าที่พวกเขาเพิ่มเข้ามาอาจน้อยมาก แต่การที่ตอนนี้แม้แต่สิ่งนั้นก็ยังหาตัวแทนได้ยากจนผู้ใช้ต้องลำบาก ก็เป็นประเด็นที่ชวนให้คิด
• สุดท้ายมันก็เกี่ยวกับ CSR(ความรับผิดชอบต่อสังคมขององค์กร) ด้วย และก็เป็นการเปลี่ยนผ่านที่เกิดขึ้นได้เพราะ CSR เช่นกัน กฎระเบียบ EU Cyber Residence Act อาจทำให้ระบบนิเวศโอเพนซอร์สเปลี่ยนไปมาก จากนี้บริษัทที่ขายสินค้าบนฐานโอเพนซอร์สเชิงพาณิชย์จะต้องปฏิบัติตามข้อกำหนดด้านความปลอดภัยและเอกสารอย่างเข้มงวด แม้โครงการโอเพนซอร์สล้วน ๆ จะไม่เข้าข่าย แต่ถ้าขายการแจกจ่ายแบบมีค่าบริการก็จะเกิดภาระทางกฎหมาย สุดท้ายการขาย compliance framework ในรูปแบบบริการอาจกลายเป็นโอกาสใหม่
  • ไม่ได้แปลว่าเพราะ CSR แล้วต้องขายเฉพาะ security images แบบเสียเงินเสมอไป ถ้าต้องการก็ยังให้ฟรีได้ หรือจะเก็บเงินเฉพาะเชิงพาณิชย์ก็ได้
  • ถ้าขายบริการเชิงพาณิชย์แบบโอเพนซอร์สบวกบริการเพิ่ม งานด้าน compliance ให้สอดคล้องกับ CSR ก็เป็นสิ่งจำเป็น สุดท้ายไม่ว่าจะเปิดหรือเชิงพาณิชย์ก็ต้องลงแรงพอ ๆ กัน
• ถ้าต้องการทางเลือก ทีม Twistlock ได้เปิดตัว Minimus บิลด์จากซอร์สโดยตรงและส่งมอบ images ที่แทบไม่มีช่องโหว่อย่างต่อเนื่อง พร้อมทำ drop-in replacement แบบเดียวกับ Bitnami ด้วย ถ้ามีคำถามเรื่องการใช้งาน เครื่องมือ หรือกรณีศึกษาลูกค้า ถามมาได้เสมอ ดู โพสต์เปรียบเทียบและคำแนะนำ
  • ฟอร์มสมัคร ของ Minimus แยก "บุคคล" กับ "องค์กร" แต่กลับบังคับกรอกชื่อบริษัท ซึ่งดูแปลกและเหมือนมีไว้เพื่อการตลาดอย่างเดียว
  • จะสรุปตัวอย่างเปรียบเทียบ Minimus กับ Bitnami Secure Images ในบล็อกให้เข้าใจง่ายขึ้นอีกหน่อย: Bitnami Secure Images บิลด์บน Photon และเมื่อมีช่องโหว่หรือมีการปล่อยเวอร์ชันใหม่ ระบบจะบิลด์ ทดสอบ และปล่อยใช้งานให้อัตโนมัติ ผู้ใช้แค่ใช้รุ่นล่าสุดก็พอ จึงไม่ต้องคอยมอนิเตอร์ CVE หรือแพตช์เอง
  • เรื่องราคาคือประเด็นใหญ่ที่สุด เคยสนใจ Chainguard กับ Docker secure images เหมือนกัน แต่พอได้ยินราคาก็เลิกสนใจ ขณะที่เว็บของ Minimus ไม่มีข้อมูลราคาเลย ก็เลยยิ่งสงสัยว่าอาจแพงเกินกว่าที่คนส่วนใหญ่จะใช้ไหวหรือเปล่า
  • สงสัยว่า Minimus เป็น OS หรือไม่ เพราะ Bitnami เองก็ยังเป็นโครงการโอเพนซอร์สที่สามารถบิลด์ image จากซอร์สได้โดยตรง
  • อยากให้ฝั่ง Minimus ทำ docker-credential helper เองโดยตรง คล้าย docker-credential-cgr ของ Chainguard แล้วจัดให้ใช้งานด้วย อย่าจบแค่บอกว่า "docker รองรับ credential store ก็ไปจัดการกันเอง" อ้างอิง
• พอเห็นค่าลิขสิทธิ์แล้วอยู่ที่มากกว่า $50,000 ต่อปี ก็รู้เลยว่าไม่ใช่ตลาดเป้าหมายของฉัน
  • ในคำอธิบายทางการเขียนว่า "BSI ทำให้ความปลอดภัยและ compliance ของโอเพนซอร์สเป็นประชาธิปไตยมากขึ้น" แต่ $50,000 ก็ไม่ใช่ระดับที่เรียกว่า "ทำให้เข้าถึงได้สำหรับทุกคน" เลย
  • คำศัพท์อาจทำให้สับสนอยู่บ้าง แต่ในทางปฏิบัติคือกำลังเปลี่ยน images จำนวนมากที่เคยให้ฟรีให้กลายเป็นแบบเสียเงิน ยังดาวน์โหลด Docker files ได้ และยังใช้ images บน Docker Hub ได้ เพียงแต่ส่วนที่ให้ฟรีจะเป็นสำหรับ "development" เท่านั้นและมีข้อจำกัดสำหรับการใช้ใน production ส่วน images แบบ "secure" จริง ๆ จะบิลด์จาก Photon OS และผ่านกระบวนการด้านความปลอดภัยด้วย ไม่ได้มีการปิดกั้นอะไรนอกเหนือจากบริการที่ให้
  • เป็นกลยุทธ์ทำเงินที่ง่ายที่สุดแบบหนึ่ง คือปล่อยฐานผู้ใช้เดิมไว้โดยไม่อัปเดตอะไรเพิ่ม ซึ่งก็มีมุมที่ชวนขำอยู่เหมือนกัน
• เกือบสองปีก่อนเคยแนะนำให้ฝั่งเอ็นเตอร์ไพรส์ย้ายออกจาก Bitnami และตอนนี้โปรเจกต์นั้นก็น่าจะเพิ่งใกล้จบ จึงรู้สึกภูมิใจที่คาดการณ์ถูก
• เมื่อมองคู่กับการเปลี่ยนแปลงไลเซนส์ของ VMware ก็ยิ่งชัดว่า Broadcom กำลังจะรับบท Oracle เวอร์ชันใหม่ น่าเสียดายที่การแข่งขันช่วงนี้ดุเดือดขึ้นมาก
  • กำลังรอดูด้วยความ "คาดหวัง" ว่า Broadcom จะทำเงินจากระบบนิเวศ Spring ยังไง เพราะแทบทุกบริษัทใหญ่ก็ใช้ Spring อยู่แล้ว เลยมองว่าเดี๋ยวเรื่องนี้ก็ต้องเกิดขึ้นอย่างหลีกเลี่ยงไม่ได้
  • จริง ๆ แล้ว Broadcom ในปัจจุบันก็คือ Avago Technologies ที่ซื้อชื่อมาใช้ในช่วง 2015–2016 ส่วนขอบเขตธุรกิจและ IP ของ Broadcom ตัวจริงนั้นส่วนใหญ่ถูกขายไปหมดแล้ว
  • ถ้ารู้ว่า Broadcom "โหด" แค่ไหน อาจรู้สึกว่าประเด็นนี้เองก็ไม่ได้ใหญ่อะไรมาก แต่ในระยะสั้นฝั่งผู้ใช้อาจยังได้ประโยชน์อยู่ก็ได้
  • คิดว่าวิศวกรของ Bitnami จำนวนมากก็คงไม่ได้เห็นด้วยกับการตัดสินใจแบบนี้ทั้งหมด
  • ตราบใดที่ Microsoft ยังอยู่ Broadcom กับ Oracle ก็ยังต้องแย่งกันเป็นอันดับ 2 ในตาราง "ความชั่วร้าย"
• โปรเจกต์ซอฟต์แวร์มีอยู่แค่สองแบบ: (1) โค้ดที่เราดูแลเองหรือจ่ายเงินให้ดูแล และ (2) โค้ดขยะที่วันหนึ่งจะต้องถูกแทนที่ด้วยเวอร์ชันที่เข้ากันไม่ได้ ต่อให้การเอาโค้ดขยะหลายตัวมาต่อกันจะเป็นการพนันที่ฉลาดพอสมควร แต่ถ้าซอร์สของ dependency มาจากบุคคลที่สาม ก็ไม่ควรคาดหวังเด็ดขาดว่าพวกเขาจะดูแลมันไปเกือบตลอดกาล การบริหารความเสี่ยงที่แท้จริงคือต้องสมมติว่าอายุของโปรเจกต์นั้นจะสั้นกว่า dependency ของมัน
• น่าเสียดายที่ Broadcom ทำแม้แต่เรื่องเล็ก ๆ อย่าง mobile padding ยังไม่ค่อยได้เรื่อง แต่ถ้าจะว่าไปก็แค่สร้าง docker.io/bsi แยกออกมา แล้วปล่อย /bitnami เดิมไว้เป็นเวอร์ชันเก่า ทุกอย่างก็ไม่พัง ผู้ใช้ก็ค่อยย้ายกันเองได้ และยังอธิบายได้อย่างเป็นธรรมชาติว่าทำไมถึงไม่มีอัปเกรด
  • ถ้า Bitnami ต้องการหยุดอัปเดตความปลอดภัยฟรี ก็ควรทำให้ผู้ใช้ต้องยอมรับความเสี่ยงนั้นด้วยตัวเอง หลังประกาศล่วงหน้าให้เพียงพอแล้ว ค่อยย้าย /bitnami ไปเป็น /bitnamilegacy ก็ยังเป็นวิธีที่โอเค
  • ชื่อ "bitnami" เองก็มีมูลค่าทางแบรนด์ ดังนั้นการใช้ชื่อนี้ต่อไปกับบริการใหม่ก็เป็นตัวเลือกที่สมเหตุสมผลในเชิงธุรกิจ
  • ปัญหาเรื่อง padding ของ Broadcom ก็ให้ความรู้สึกเดียวกับที่ UI ของ Rally ดูเก่าเกินไป
• ฉันไม่เข้าใจ convention ของ images และ packages ของ Bitnami เลย พอใช้จริงกลับซับซ้อนมากและกฎเฉพาะตัวก็น่ารำคาญ ไม่ใช่แพ็กเกจง่าย ๆ ที่อยู่บนเบสปกติ แต่เป็นโครงสร้างประหลาด ๆ และพอจะเปลี่ยนอะไรสักอย่างก็วุ่นวายไปหมด
  • พวกเขาไม่สน convention ทั่วไปของคนอื่นเลย แล้วก็ซ้อนสคริปต์ซับซ้อนทับลงไป ทำให้ทุก image ต้องอ่านเอกสารเฉพาะก่อนถึงจะใช้ได้ แถมยังไม่ตรงกับเอกสารทางการปกติอีก เลยน่าหงุดหงิดมาก
  • ช่วงหนึ่งเคยใช้ image ของ Bitnami เพราะอยากได้ base image ที่รันแบบ rootless ได้ง่าย ตอนนั้นในรีโพทางการ การตั้งค่า postgres ฯลฯ ให้เป็น rootless ยังทำได้ยาก แต่ image ของ Bitnami แต่ละตัวก็มี uid หรือ path ของ config ไม่เหมือนกัน เลยต้องคอยเปิด Dockerfile อ่านทีละตัวเสมอ
  • เดิมที Bitnami เคยได้รับความนิยมเพราะเอาไว้รัน Wordpress บน Windows พวกเขาทำให้ใช้บน Windows Server ได้ทันที ซึ่งในยุคนั้นมีประโยชน์มาก ทุกวันนี้ถ้ายังทำงานแบบนั้นอาจโดนไล่ออกได้ แต่ตอนนั้น Linux ยังไม่ได้แพร่หลายมาก จึงเป็นบริการที่จำเป็น
  • สงสัยว่ามีแหล่งข้อมูลไหนที่ใช้อ้างอิงเรื่อง packaging conventions แบบนี้ได้บ้าง เพราะดูเหมือนธรรมเนียมทั่วไปคือใช้ official image ของโปรเจกต์เป็นฐาน แล้วค่อยปรับแต่งและสร้าง image ภายในของตัวเองกัน