1 ปีของการสนับสนุนการพัฒนา FreeBSD

 (daemonology.net)
2 คะแนน โดย GN⁺ 2025-06-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ได้รับการสนับสนุนจาก Amazon เป็นเวลา 1 ปีเพื่อทำงานด้าน วิศวกรรมการออกรีลีสของ FreeBSD และการพัฒนา FreeBSD/EC2
  • ดำเนินงานทั้งด้าน การจัดการรีลีส และการปรับปรุงที่เกี่ยวข้องกับ EC2 ควบคู่กัน โดยใช้เวลาทำงานเฉลี่ยเดือนละ 50 ชั่วโมง
  • บรรลุการแก้ปัญหาฟีเจอร์สำคัญและการยกระดับคุณภาพ เช่น การจัดการพลังงานของอินสแตนซ์ Graviton, การรองรับ hotplug, และการปรับปรุงประสิทธิภาพการบูต
  • ขยาย ประเภทของ AMI และทำระบบอัตโนมัติสำหรับการบิลด์ เพื่อเพิ่มความหลากหลายและประสิทธิภาพในการเผยแพร่ FreeBSD AMI
  • หลังการสนับสนุนสิ้นสุดลง คาดว่าความเร็วในการพัฒนาจะช้าลง และการพัฒนาฟีเจอร์บางส่วนอาจหยุดชะงัก

ทบทวน 1 ปีของการสนับสนุนการพัฒนา FreeBSD

# ที่มาและกระบวนการของการสนับสนุน

  • ดูแลแพลตฟอร์ม FreeBSD/EC2 มาตั้งแต่ปี 2010 และตั้งแต่เดือนพฤศจิกายน 2023 ก็รับบทเป็นหัวหน้าฝ่ายวิศวกรรมการออกรีลีสของ FreeBSD ด้วย
  • แม้จะได้รับการสนับสนุนขนาดเล็กจาก Antithesis, Patreon และที่อื่น ๆ อยู่ก่อนแล้ว แต่งานด้านวิศวกรรมรีลีสได้เบียดบังเวลาสำหรับการพัฒนา FreeBSD/EC2 ไปอย่างมาก
  • มีการพูดคุยเรื่องสปอนเซอร์สำหรับงาน EC2 กับทาง Amazon มานานหลายปี และในเดือนเมษายน 2024 ก็ได้ติดต่อกับผู้รับผิดชอบด้านงบประมาณ จนได้รับการสนับสนุนเป็นเวลา 1 ปี
  • การสนับสนุนดำเนินการผ่าน GitHub Sponsors และช่วงเวลาที่ Amazon ตั้งใจจะสนับสนุนอาจไม่ตรงกับเวลาที่มีการโอนเงินจริง

# การสนับสนุนและการแบ่งเวลาทำงาน

  • ตามคำขอของ Amazon ได้ให้คำมั่นว่าจะใช้เวลา 40 ชั่วโมงต่อเดือน สำหรับงานวิศวกรรมการออกรีลีสของ FreeBSD และการพัฒนา EC2
  • ในทางปฏิบัติใช้เวลาประมาณ 50 ชั่วโมงต่อเดือน โดยแบ่งเป็น 20 ชั่วโมงสำหรับประเด็น EC2, 20 ชั่วโมงสำหรับงานรีลีส, และอีก 10 ชั่วโมงสำหรับงานวิศวกรรมอื่น ๆ
  • ชั่วโมงการทำงานในแต่ละเดือนมีความผันผวนค่อนข้างมาก

# การจัดการรีลีสของ FreeBSD

  • มีการนำตารางรีลีสแบบรายไตรมาสของ FreeBSD มาใช้และดูแลจัดการ จนในช่วง 1 ปีมีการออกรีลีส 4 ครั้ง: FreeBSD 13.4(2024.9), 14.2(2024.12), 13.5(2025.3), 14.3(คาดการณ์ 2025.6)
  • ในแต่ละรีลีส มีทั้งการกระตุ้นให้นักพัฒนาส่งโค้ดให้ทันกำหนด, อนุมัติและประสานงานคำขอ merge, บิลด์และทดสอบอิมเมจ, เขียนประกาศ, และแก้ข้อผิดพลาดต่าง ๆ ในการบิลด์รีลีส
  • เวลาที่ใช้กับงานวิศวกรรมรีลีสในแต่ละไตรมาสอยู่ที่ราว 33.5~79 ชั่วโมง และมีแนวโน้มว่างานลดลงในช่วงหลังเมื่อระบบมีเสถียรภาพมากขึ้น

# การปรับปรุงฟีเจอร์ EC2 สำคัญและการยกระดับคุณภาพ

ไดรเวอร์พลังงานของอินสแตนซ์ Graviton และการรองรับ hotplug

  • แก้ปัญหาที่ FreeBSD ไม่สามารถรับรู้สัญญาณปิดเครื่องตามปกติจาก EC2 API บนอินสแตนซ์ Graviton ได้

    • ใช้ออบเจ็กต์ ACPI _AEI เพื่อเชื่อมสัญญาณ "power button" แบบ GPIO เข้ากับลอจิกของไดรเวอร์
    • สำหรับปัญหาที่อุปกรณ์ถูกปิดใช้งานจากความไม่ตรงกันของการตั้งค่า Pull Up flag ในตาราง ACPI ที่ EC2 จัดให้ ได้แก้ด้วยการเพิ่มการตั้งค่า ACPI_Q_AEI_NOPULL ใน FreeBSD/EC2 AMI

  • วิเคราะห์และแก้ปัญหา hotplug ของอุปกรณ์ (โดยเฉพาะ hot unplug) บนอินสแตนซ์ EC2 ทั้ง Graviton และ x86 อย่างครอบคลุม

    • รับมือกับบั๊กหลากหลายประเภท เช่น IRQ รั่ว, สถานะพลังงาน PCI ไม่ตรงกับสัญญาณจาก OS, และอุปกรณ์ PCI แบบ "ผี"
    • ใช้ ACPI quirk เป็นมาตรการชั่วคราว (เช่น ACPI_Q_CLEAR_PME_ON_DETACH, ACPI_Q_DELAY_BEFORE_EJECT_RESCAN) ขณะที่บั๊กฝั่ง EC2 มีกำหนดแก้ไขภายหลัง

การทำระบบอัตโนมัติสำหรับการทดสอบ hotplug และการปรับปรุงคุณภาพ

  • พัฒนาสคริปต์สำหรับเชื่อมต่อและถอด EBS volume ซ้ำ ๆ ในสภาพแวดล้อม EC2 และตรวจสอบเสถียรภาพผ่านการทดสอบต่อเนื่อง 300 ครั้ง
  • ปรับปรุงคุณภาพโดยตั้งค่าดีเลย์ 5 วินาทีที่ไม่จำเป็นของ PCIe hotplug (ซึ่งมีความหมายเฉพาะบนระบบจริง) ให้เป็น 0 วินาทีบน EC2

การปรับปรุงประสิทธิภาพการบูต

  • ปรับปรุงความเร็วการบูตของ FreeBSD/EC2 อย่างเป็นระบบผ่านการเก็บและวิเคราะห์ข้อมูล
  • แก้ปัญหาตามลำดับ เช่น การบูตช้าลง 3 เท่าเพราะเพิ่มขนาดดิสก์ root ในช่วงต้นปี 2024, ความล่าช้าในการ seed entropy ของเคอร์เนลบนอินสแตนซ์ Graviton2, เวลาในการบูต ZFS ที่เพิ่มขึ้น, และปัญหาการรองรับ IPv6 ที่เกี่ยวข้องกับ IMDSv2
  • มีการปรับจูนในหลายด้าน ทั้งความต่างของประสิทธิภาพการบูตตาม filesystem, ความไม่มีประสิทธิภาพในการจัดหา entropy, และความล่าช้าในการเริ่มต้นเครือข่าย

# ขยายความหลากหลายของ FreeBSD AMI และทำระบบอัตโนมัติสำหรับการบิลด์/เผยแพร่

  • นอกจาก AMI แบบ base และ cloud-init เดิมแล้ว ยังเพิ่ม small AMI (ตัดโค้ด/เครื่องมือสำหรับดีบักและทดสอบที่ไม่จำเป็นออก ขนาด 1GB) และ builder AMI (บิลเดอร์สำหรับการปรับแต่งของผู้ใช้)
  • เมื่อชุดอิมเมจขยายเป็น 4 ประเภท AMI * 2 filesystem(UFS/ZFS) * 2 สถาปัตยกรรม(amd64/arm64) * 3 เวอร์ชัน(13, 14, 15) จึงมีการทำสคริปต์และลบอิมเมจเก่าอัตโนมัติ พร้อมจัดการ EBS snapshot ไปแล้ว 336TB

# การปรับปรุงด้านวิศวกรรมทั่วไป

  • ทำ parallelization ให้กับการบิลด์ FreeBSD AMI/รีลีส ทำให้เวลาบิลด์รวมลดลงจากประมาณ 22 ชั่วโมงเหลือ 13 ชั่วโมง และมีพื้นที่สำหรับเพิ่มประเภท AMI ได้มากขึ้น
  • ใช้การทดสอบอัตโนมัติบนอินสแตนซ์ EC2 และการเปรียบเทียบด้วย diffoscope เพื่อวิเคราะห์และแก้ปัญหา build reproducibility (reproducible build)
  • ควบคู่ไปกับงานย่อยอีกหลายอย่าง เช่น รีวิวแพตช์ไดรเวอร์ ENA, บิลด์ OCI container และอัปโหลดขึ้นรีจิสทรี, ปรับปรุงเครื่องมือที่เกี่ยวข้องกับ AWS, และรายงานประเด็นด้านความปลอดภัย

# แนวโน้มข้างหน้าและข้อจำกัด

  • ยังจะคงบทบาทด้านวิศวกรรมการออกรีลีสของ FreeBSD และการดูแลแพลตฟอร์ม EC2 ต่อไป แต่คาดว่าเวลาที่สามารถทุ่มให้ได้จะน้อยลงกว่าเดิม
  • รีลีส FreeBSD 15.0(ธันวาคม 2024), 14.4/15.1/14.5/15.2(ปี 2026) จะยังดำเนินไปตามแผน แต่ความเร็วในการเพิ่มฟีเจอร์/แก้บั๊กน่าจะลดลง
  • งานที่ยังไม่เสร็จ เช่น การขยาย filesystem อัตโนมัติ, หลาย NIC และระบบอัตโนมัติสำหรับ hotplug, การแจกจ่าย AMI ที่แพตช์ไว้ล่วงหน้า, เว็บทูลสำหรับผู้ใช้ EC2, และการรองรับ FreeBSD/Firecracker มีแนวโน้มจะชะงักในระยะยาว

# ปิดท้าย

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

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

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

 
GN⁺ 2025-06-07
ความคิดเห็นจาก Hacker News

  • แชร์ข่าวว่ามีการเพิ่ม FreeBSD ลงในหน้าดาวน์โหลดของ ziglang.org แล้ว ตอนนี้ผู้ใช้ FreeBSD สามารถรับบิลด์จาก master branch ที่สร้างอัตโนมัติจาก CI ได้ง่ายขึ้น
    ตอนนี้ FreeBSD ได้รับการรองรับอย่างเป็นทางการเต็มรูปแบบในฐานะเป้าหมายสำหรับ cross compile แล้ว สามารถคอมไพล์โดยเล็งเป้าไปที่ FreeBSD แบบเดียวกับ Linux ได้ เช่น zig cc -o hello hello.c -target riscv64-freebsd
    หากมี dependency แบบ C/C++ ก็สามารถดึงเข้ามาและบิลด์ได้ง่ายด้วยระบบบิลด์ของ zig ทำให้แม้แต่โปรเจ็กต์ที่ค่อนข้างซับซ้อนก็ cross compile ไปยัง FreeBSD ได้ไม่ยาก
    หวังว่าจากเรื่องนี้จะทำให้โปรเจ็กต์ต่าง ๆ เพิ่มการรองรับและการทดสอบ FreeBSD เข้าไปใน CI มากขึ้น

    • พูดถึงว่าความสามารถด้าน cross compile ของ Zig เจ๋งมาก และยินดีที่มีการเพิ่ม FreeBSD เข้ามาเป็นเป้าหมายที่รองรับ

  • อ่านแล้วมีหลายช่วงที่น่าสนุก
    มีกรณีที่ตั้งแต่สัปดาห์แรกของปี 2024 กระบวนการบูตของ FreeBSD ช้าลงกะทันหัน 3 เท่า หลังจากไล่ตาม commit ไปเรื่อย ๆ ก็พบว่าสาเหตุมาจากการเพิ่มขนาด root disk จาก 5GB เป็น 6GB
    พอลองถามเพื่อนที่ Amazon ก็ได้คำตอบประมาณว่า “ไม่รู้แน่ชัดหรอก แต่ไม่รู้ไว้ก็น่าจะดีกว่า” ราวกับเป็นเวทมนตร์อะไรสักอย่าง
    ที่สำคัญคือเมื่อเพิ่มขนาด root disk เป็น 8GB ประสิทธิภาพก็กลับมาอยู่ในระดับเดิม

    • พอได้ยินเรื่องแบบนี้แล้วก็ยิ่งอยากรู้จริง ๆ ว่าเหตุผลคืออะไร

    • สงสัยว่าใช้เวลาจริง ๆ ไปเท่าไรกับการ bisect commit เพื่อหาปัญหาแบบนี้
      แอบนึกภาพว่าต้องสร้างอิมเมจใหม่แล้วรีบูต VM ทุกครั้งหรือเปล่า

    • มีการอ้างถึงโพสต์บล็อกของตัวเองในปี 2006 ว่าขนาดสูงสุดของออบเจ็กต์แบบดั้งเดิมของ S3 เคยอยู่ที่ 5GB
      https://aws.amazon.com/blogs/aws/amazon_s3/
      ไม่แน่ใจว่านี่เกี่ยวข้องโดยตรงกับอาการที่ FreeBSD ช้าลงหรือไม่

  • ยังมีงานอีกมากเกี่ยวกับการรองรับโน้ตบุ๊ก
    อ่านเจอว่ามูลนิธิ BSD ลงทุน $750,000 เพื่อโฟกัสกับฟีเจอร์ต่าง ๆ เช่น การทำ S0ix Sleep State และอื่น ๆ
    ดูโปรเจ็กต์ที่เกี่ยวข้องได้ที่ https://github.com/FreeBSDFoundation/proj-laptop

    • ตอนนี้มีงานจำนวนมากเกิดขึ้นพร้อมกันจริง ๆ แต่ที่ผู้เขียนแชร์นั้นเขียนเฉพาะส่วนที่ตัวเองกำลังทำอยู่เท่านั้น

  • เดิมหวังว่า Amazon จะสนับสนุนและมีส่วนร่วมมากกว่านี้ แต่ความจริงดูเหมือนจะอยู่แค่ระดับสนับสนุนขั้นต่ำต่อ FreeBSD
    Amazon ไม่มีชื่ออยู่ในรายชื่อผู้สนับสนุนของ FreeBSD ด้วยซ้ำ Google ปีที่แล้วก็บริจาคเพียง $9K เท่านั้น และ Apple กับ Meta/Facebook ก็ไม่มีเช่นกัน
    ในทางกลับกันก็ขอชื่นชมที่ Microsoft มีชื่ออยู่ในรายชื่อ
    ค่อนข้างน่าแปลกใจที่บริษัทยักษ์ใหญ่เหล่านี้ได้ประโยชน์จาก FreeBSD และ OpenBSD มาก แต่ไม่ได้บริจาคแบบอัตโนมัติทุกปี
    ข้อมูลผู้สนับสนุนดูได้ที่ https://freebsdfoundation.org/our-donors/donors/?donationYear=2024

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

    • มีข้อสังเกตว่าด้วยคอมเมนต์นี้เพียงอย่างเดียวอาจมองภาพรวมทั้งหมดไม่ได้
      สิ่งที่เห็นเป็นแค่ snapshot ของเงินบริจาคให้มูลนิธิในแต่ละปี ส่วนงานพัฒนาที่มีการ contribute นั้นสรุปไว้ใน release notes ของแต่ละรุ่น
      https://www.freebsd.org/releases/

    • สงสัยว่าทำไม Microsoft ถึงสนับสนุน FreeBSD
      ส่วนขยาย Hyper-V ก็ยังไม่สมบูรณ์เท่า Linux, ไม่มี official port ของ .NET และก็ดูไม่เหมือนว่า Microsoft จะให้บริการที่อิง FreeBSD อยู่

    • ความเห็นหนึ่งมองว่า Amazon เป็นบริษัทในกลุ่ม FAANG ที่ contribute ให้ FOSS น้อยที่สุด

  • แสดงความเคารพต่อ cperciva อย่างมาก
    สงสัยว่าเขาจัดการดูแลทั้ง Tarsnap และ FreeBSD ไปพร้อมกันได้อย่างไร

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

  • เคยมีประสบการณ์ใช้ FreeBSD เป็นเวิร์กสเตชันมาก่อน และรู้สึกประทับใจ
    อยากใช้ FreeBSD เป็น home gateway/firewall/DNS/DHCP server แต่สุดท้ายเลือก Nix เพราะ NIC 10GbE ไม่รองรับไดรเวอร์
    ดีที่ได้เห็นว่า FreeBSD ยังคงได้รับการดูแลอย่างดี

  • สงสัยว่าใครคือผู้ใช้รายใหญ่ของ FreeBSD/EC2

    • ตัวผู้เขียนเองก็ไม่รู้เหมือนกัน
      จริง ๆ แล้วผู้ใช้ที่ติดต่อเขามาคงมีไม่ถึง 0.1% ของผู้ใช้ FreeBSD/EC2 ทั้งหมด
      เขาเองก็อยากรู้จริง ๆ ว่าใครใช้ FreeBSD บน EC2 อยู่บ้าง

    • สงสัยว่า Netflix ใช้ FreeBSD เฉพาะกับ edge box เท่านั้นหรือไม่

  • สงสัยว่า FreeBSD เข้ามาเติมเต็ม niche อะไรในตระกูล Unix
    ถามว่าทำไมถึงเลือกใช้ FreeBSD ที่ซับซ้อนกว่า OpenBSD หรือ NetBSD และถ้าต้องการ ZFS, Nvidia หรือ ELF ทำไมไม่ใช้ Linux ไปเลย
    รู้เรื่องปัญหาของ GNU อยู่แล้ว แต่ก็ยังมีทางเลือกอย่าง Musl Void จึงอยากรู้ด้วยความสงสัยจริง ๆ ว่า “อัตลักษณ์” ที่ชัดเจนของ FreeBSD คืออะไร

    • มีประสบการณ์ใช้ FreeBSD ในแวดวงการเงิน ทั้งบน EC2 และบนเซิร์ฟเวอร์จริงในดาต้าเซ็นเตอร์ของตัวเอง
      ใช้ zfs และ jails อย่างมาก
      รันทุกบริการแยกกันในแต่ละ jail ทำให้คุ้มค่าด้านต้นทุนมาก
      พอย้ายบางส่วนขึ้นคลาวด์และทำงานแบบไฮบริด Linux(k8s)+FreeBSD ค่าใช้จ่ายกลับเพิ่มขึ้นมาก
      การดูแลดาต้าเซ็นเตอร์เองมีความยุ่งยากอย่างการเปลี่ยนดิสก์หรือรับมือเหตุไฟไหม้ แต่ AWS ก็มีความสามารถอย่าง multi-region ให้ใช้ด้วย (แลกกับต้นทุนที่สูงขึ้น)
      zfs เคยช่วยมากตอนที่ตารางฐานข้อมูล production ถูกลบโดยไม่ตั้งใจ เพราะสามารถ rollback ได้ทันทีจาก snapshot และยังใช้ zfs สำหรับแบ็กอัปด้วย
      อีกทั้งยังเคยใช้ dtrace แก้ปัญหาใน production
      ตอนที่ใช้ FreeBSD อย่างเดียวบนเซิร์ฟเวอร์ การมี OS ตระกูลเดียวทำให้จัดการง่าย แต่เมื่อเริ่มมี Linux แต่ละทีมก็ใช้ดิสโทรต่างกันจนเกิดความสับสน
      ชอบ FreeBSD ในฐานะโครงสร้างที่รวม kernel+OS เข้าด้วยกัน

    • สำหรับตัวเขาเอง FreeBSD ให้ความรู้สึกเหมือนเป็นการผสมข้อดีของ OpenBSD และ NetBSD อย่างลงตัว
      ในอดีต FreeBSD เด่นเรื่องการปรับแต่งเพื่อ Intel CPU และมีความปลอดภัยที่แข็งแกร่ง โดยเฉพาะการรองรับ ZFS ที่เป็นจุดแตกต่างสำคัญ
      ไดรเวอร์ nvidia เองก็เพิ่งมีการรองรับ FreeBSD แบบ native เมื่อไม่นานมานี้
      สุดท้ายแล้ว FreeBSD คือการรวมจุดแข็งของ BSD อื่น ๆ เข้ากับเสถียรภาพด้านฮาร์ดแวร์ได้ดี

    • จุดหนึ่งคือ FreeBSD มีฐานผู้ใช้ใหญ่กว่า OpenBSD หรือ NetBSD มาก
      ตัว catalog ซอฟต์แวร์ก็ใหญ่กว่ามากพอที่จะใช้งานเดสก์ท็อปในชีวิตประจำวันได้สบาย
      ส่วนเหตุผลที่ไม่ใช้ Linux คือ Linux ผูกพันกับผลประโยชน์ขององค์กรธุรกิจมากเกินไป

    • มีความเห็นว่า FreeBSD เหนือกว่า Linux ในเรื่องการรองรับ ZFS
      ด้วยปัญหาด้านไลเซนส์ FreeBSD จึงให้สภาพแวดล้อมที่ดีกว่า

    • FreeBSD เหนือกว่า OpenBSD ในด้าน throughput ของงานเครือข่าย
      โดยทั่วไป BSD ทั้งหลายเปลี่ยนแปลงช้ากว่า จึงเหมาะกับการใช้เป็นแพลตฟอร์มแบบบูรณาการ

  • มีความเห็นว่าบทความนี้ทำให้สภาพแวดล้อมการพัฒนา FreeBSD ดูไม่ค่อยดีนัก
    เมื่อคำนึงว่านี่เป็น OS ที่มีความซับซ้อนสูง ก็น่าจะอย่างน้อยมีใครสักคนทำหน้าที่ release manager แบบเต็มเวลา แต่ความจริงคือมีเพียงงานพาร์ตไทม์ตลอดหนึ่งปี ซึ่งน่าเสียดาย
    ถึงอย่างนั้น การมีอยู่ของ FreeBSD ก็ยังสำคัญในฐานะเครื่องยืนยันว่า Linux ไม่ใช่ทางเลือกเดียว