การสนับสนุนการพัฒนา FreeBSD ตลอด 1 ปี

 (daemonology.net)
2 คะแนน โดย GN⁺ 2025-06-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในสถานการณ์ที่การดูแล FreeBSD/EC2 และงานวิศวกรรมรีลีสชนกันภายในเวลางานอาสาสมัครของคนคนเดียว การสนับสนุน 1 ปีจาก Amazon ทำให้สามารถเดินหน้าทั้ง การดำเนินงานรีลีส และ การปรับปรุงแพลตฟอร์ม EC2 ได้พร้อมกัน
  • การสนับสนุนมีขนาดในนามเดือนละ 40 ชั่วโมงผ่าน GitHub Sponsors แต่เวลาทำงานจริงเฉลี่ยอยู่ที่ 50 ชั่วโมงต่อเดือน โดยแบ่งคร่าว ๆ เป็นปัญหา EC2 20 ชั่วโมง, การดำเนินรีลีส 20 ชั่วโมง, และงานวิศวกรรมรีลีสอื่น ๆ 10 ชั่วโมง
  • ตลอด 1 ปี มีการดูแลรีลีส FreeBSD 13.4, 14.2, 13.5, 14.3 พร้อมกับทำงานลำดับความสำคัญสูงอย่าง การจัดการสัญญาณปิดเครื่อง บน AWS Graviton และ device hotplug บน EC2 ไปพร้อมกัน
  • เพื่อจับ regression ด้านประสิทธิภาพการบูต จึงทำ benchmark รายสัปดาห์ของ EC2 AMI builds ย้อนหลังถึงปี 2018 และพบพร้อมแก้ไขสาเหตุของความหน่วงจากขนาด root disk, การ seed entropy ผ่าน EFI, ZFS transaction group และการเปลี่ยนแปลง IMDSv2 IPv6
  • แม้หลังการสนับสนุนสิ้นสุด บทบาทต่าง ๆ จะยังดำเนินต่อไป แต่เวลาที่ทุ่มได้จะลดลง ทำให้การแก้ปัญหาโดยตรงก่อนรีลีสหรือการผลักดันรายการฟีเจอร์ EC2 ต่อเนื่องทำได้ยากขึ้น

คอขวดก่อนมีการสนับสนุนและการจัดสรรเวลา

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

การดำเนินงานรีลีสรายไตรมาสและการปรับปรุงการ build

  • ตาม ตารางรีลีสรายไตรมาส ของ FreeBSD ที่ประกาศในเดือนกรกฎาคม 2024 มีการดูแล 4 รีลีสในช่วง 1 ปี
    • FreeBSD 13.4: กันยายน 2024
    • FreeBSD 14.2: ธันวาคม 2024
    • FreeBSD 13.5: มีนาคม 2025
    • FreeBSD 14.3: มีกำหนดรีลีส 10 มิถุนายน 2025
  • แต่ละรีลีสครอบคลุมการกระตุ้นให้มีการ merge โค้ด, อนุมัติหรือปฏิเสธคำขอ merge, ประสานงานกับทีมอื่น, build และทดสอบ image, เขียนประกาศ, และแก้ปัญหาใน release build
    • โดยทั่วไปจะ build 3 รุ่น Beta, 1 รุ่น Release Candidate และ Release สุดท้าย
    • งานส่วนใหญ่มักไปกองอยู่ในเดือนก่อนรีลีส หรือก็คือ “Beta Month” ซึ่งเป็นเดือนที่สองของแต่ละไตรมาส
    • FreeBSD 13.5 ใช้เวลา 33.5 ชั่วโมง และ FreeBSD 14.2 ใช้เวลา 79 ชั่วโมง
    • ยิ่งเข้าใกล้ช่วงปลายของ stable branch จำนวนสิ่งที่พังมักลดลง จึงมีแนวโน้มให้งานรีลีสน้อยลง
    • แม้ไม่ได้ติดตาม FreeBSD 14.1 แต่คาดว่าเวลางานวิศวกรรมรีลีสน่าจะเกือบ 100 ชั่วโมง และ FreeBSD 15.0 มีโอกาสจะมากกว่านั้นมาก
  • ในงานวิศวกรรมรีลีสทั่วไป ยังได้ทำ parallelization ของ release build ด้วย
    • เมื่อจำนวน EC2 AMI เพิ่มขึ้น เวลาที่ใช้ติดตั้ง FreeBSD ลงใน VM image กลายเป็นสัดส่วนที่มากกว่าตัว build จริง
    • แม้จะทำให้ release code ทำงานแบบขนานได้ แต่กลับเกิดความล้มเหลวในการ build แบบประปราย และเนื่องจากทั้ง release build ใช้เวลาราว 24 ชั่วโมง การแยกสาเหตุจึงทำได้ยาก
    • สาเหตุสุดท้ายคือมี Makefile ขาดไปหนึ่งบรรทัดที่ควรสร้าง directory ก่อนติดตั้งไฟล์
    • หลังแก้ไข release build ลดเวลาจากประมาณ 22 ชั่วโมงเหลือประมาณ 13 ชั่วโมง และทำให้สามารถขยาย EC2 AMI flavour ที่เคยถูกเลื่อนเพราะเวลา build ได้
  • ปัญหาเรื่อง reproducibility ของ build ก็เริ่มตรวจสอบเป็นประจำโดยใช้ EC2
    • ในขั้นตอนทดสอบ snapshot image รายสัปดาห์ จะเปิด EC2 instance ให้ build AMI ของตัวเอง
    • ใช้ diffoscope เปรียบเทียบ disk image ที่สร้างขึ้นกับ image ต้นฉบับ
    • การทดสอบประจำช่วยให้พบหลายปัญหา ซึ่งบางส่วนแก้เองและบางส่วนส่งต่อให้นักพัฒนาคนอื่น

การจัดการพลังงานบน Graviton และ hotplug ของ FreeBSD/EC2

  • ฟีเจอร์หลักที่ Amazon ขอให้จัดลำดับความสำคัญใน FreeBSD/EC2 คือ power driver สำหรับอินสแตนซ์ AWS Graviton และ device hotplug
  • Power driver สำหรับ Graviton จัดการเส้นทางที่ EC2 API ใช้แจ้งระบบปฏิบัติการให้ปิดเครื่อง
    • หากไม่มีฟีเจอร์นี้ FreeBSD จะเพิกเฉยต่อสัญญาณปิดเครื่อง และอีกไม่กี่นาทีต่อมา EC2 จะตัดไฟเสมือนหลัง timeout
    • “ปุ่มเปิดปิด” ของระบบ Graviton คือ GPIO pin และรายละเอียดอยู่ในออบเจ็กต์ ACPI _AEI
    • จึงเพิ่มโค้ดให้ค้นหาข้อมูลดังกล่าวจาก ACPI และส่งข้อมูลการตั้งค่าไปยังไดรเวอร์ PL061 GPIO controller
    • เมื่อ GPIO pin ถูก assert ตัว controller จะสร้าง interrupt และเกิด ACPI “power button” event ที่นำไปสู่การปิดระบบ
  • ตาราง ACPI ที่ EC2 ให้มาระบุให้ตั้งค่า GPIO pin ดังกล่าวเป็น “Pull Up” แต่ PL061 controller ไม่มีตัวต้านทาน pullup/pulldown
    • Linux เพิกเฉยต่อความล้มเหลวในการตั้งค่า GPIO แบบเงียบ ๆ จึงไม่เห็นปัญหา
    • FreeBSD จะปิดการทำงานของอุปกรณ์หลังการตั้งค่าล้มเหลว
    • แม้คาดว่าในอนาคต EC2 bug นี้บน Graviton จะถูกแก้ แต่ตอนนี้ได้ใส่ quirk ACPI_Q_AEI_NOPULL ลงใน FreeBSD/EC2 AMI เพื่อเพิกเฉยต่อแฟล็ก GPIO PullUp ในออบเจ็กต์ _AEI
  • Hotplug โดยเฉพาะ hot unplug ต้องใช้เวลามากกว่า เพราะมีปัญหาหลายแบบซ้อนกันในหลายประเภทของ EC2 instance
    • บางระบบ Graviton มีการรั่วของการจอง virtual IRQ ระหว่าง PCI attach และหลัง attach/detach EBS volume 67 ครั้ง IRQ จะหมดจนทำให้ FreeBSD kernel panic
      • สาเหตุอยู่ที่โค้ด legacy PCI interrupt routing และได้เพิ่มการตั้งค่า boot loader เพื่อปิดโค้ดดังกล่าวบน EC2
    • บางระบบ Graviton ใช้สถานะพลังงานของอุปกรณ์ PCI เป็นสัญญาณตัดสินว่า OS ใช้งานอุปกรณ์เสร็จและพร้อม eject แล้วหรือไม่
      • คาดว่านี่เป็น EC2 bug และตอนนี้แก้ชั่วคราวด้วย quirk ACPI_Q_CLEAR_PME_ON_DETACH ที่เปลี่ยนบางบิตใน PCI power management register ก่อน eject
    • บนทั้ง x86 และ Graviton ของ EC2 instance รุ่นใหม่ หลัง PCIe unplug แล้ว ไดรเวอร์ FreeBSD nvme จะ panic
      • ปัญหานี้ถูกส่งต่อให้ผู้ดูแลไดรเวอร์ nvme
    • ในบาง EC2 instance ทั้ง x86 และ Graviton หลัง eject ยังมีอุปกรณ์ “ghost” ค้างอยู่บน PCI bus จนขัดขวางการ attach อุปกรณ์ใหม่
      • Nitro firmware จัดการ PCI bus และ PCI device แบบ asynchronous ทำให้มีช่วงเวลาหลาย ms ที่อุปกรณ์ถูก unplug ไปแล้ว แต่ PCI bus ยังรายงานว่าอุปกรณ์นั้นมีอยู่
      • Linux สแกน bus เป็นระยะ จึงมักแพ้ race นี้ แต่ FreeBSD จะสแกน PCI bus ใหม่ทันทีหลัง detach ทำให้เห็น ghost บ่อยกว่า
      • ตอนนี้ใช้ quirk ACPI_Q_DELAY_BEFORE_EJECT_RESCAN เพื่อเพิ่มการหน่วง 10ms หลังสัญญาณ eject ก่อน rescan PCI bus
  • PCIe กำหนดให้หลังจากกดปุ่ม “attention” เพื่อขอ eject อุปกรณ์ ต้องรอ 5 วินาที และหากมีการกดปุ่มครั้งที่สองจะยกเลิกคำขอ eject
    • บน EC2 ไม่มีคนกดปุ่มจริง และไม่มีกลไกกดปุ่มเสมือนซ้ำอีกครั้ง จึงไม่จำเป็นต้องมีการหน่วงนี้
    • จึงเพิ่ม boot loader tunable เพื่อกำหนด timeout เป็น 0 บน EC2
  • ด้วยสคริปต์ทดสอบ hotplug สามารถเปิด EC2 instance แล้วใช้ EC2 API ทำ plug/unplug EBS volume ซ้ำ ๆ เพื่อยืนยันว่า FreeBSD attach/detach ได้ต่อเนื่อง 300 ครั้ง
    • หากในอนาคตสามารถเข้าถึง EC2 instance type ใหม่ล่วงหน้า ก็จะใช้ทดสอบว่า hotplug ทำงานถูกต้องหรือไม่

การติดตาม regression ด้านประสิทธิภาพการบูตและการขยาย AMI

  • นอกจากสองงานลำดับความสำคัญสูงของ Amazon แล้ว เวลาราวครึ่งหนึ่งของเวลาที่ใช้กับ EC2 ยังถูกใช้กับปัญหา FreeBSD/EC2 อื่น ๆ
  • ช่วงปลายปี 2023 และต้นปี 2024 บางครั้ง FreeBSD/EC2 instance บูตช้ากว่าที่คาด และในการทดสอบ snapshot รายสัปดาห์ จำเป็นต้องเพิ่มเวลารอก่อนพยายามเชื่อมต่อ SSH หลังจากเปิด instance
  • เพื่อจัดการปัญหาด้านประสิทธิภาพ จึงทำ benchmark เวลาบูตของ EC2 AMI builds รายสัปดาห์ย้อนหลังถึงปี 2018
    • ในกระบวนการนี้มีการเปิดใช้ EC2 instance มากกว่า 10,000 เครื่อง
    • เริ่มสร้าง boot performance plots ของ FreeBSD
    • การเก็บข้อมูลใหม่และอัปเดตกราฟถูกผนวกรวมเข้าในกระบวนการทดสอบ snapshot รายสัปดาห์
  • มีการค้นหาและแก้ไข สาเหตุหลายประการของความหน่วงในการบูต
    • ตั้งแต่สัปดาห์แรกของปี 2024 การบูต FreeBSD ช้าลงราว 3 เท่า และไล่ต้นตอไปถึง commit ที่เพิ่มขนาด root disk จาก 5GB เป็น 6GB
      • หลังตรวจสอบกับฝั่ง Amazon พบว่าหากเพิ่มขนาด root disk เป็น 8GB ประสิทธิภาพจะกลับมาใกล้ระดับเดิม
    • ในตระกูล Graviton 2 การบูตช้ายาวขึ้นเพราะปัญหา kernel entropy seeding
      • FreeBSD kernel จะหยุดการบูตไว้หากมี entropy ไม่พอสำหรับสร้าง random number ที่ปลอดภัย จนกว่าจะเก็บ entropy เพิ่มได้
      • เดิมมีโค้ดรับ secure seed จาก Nitro firmware ผ่าน EFI boot loader แต่ไม่ได้ถูกรันบน EC2 และบน Graviton 2 การขอ 2048 ไบต์ทำได้ช้ามาก
      • จึงย้ายคำขอจากโค้ด Lua ของเมนูบูตไปยังตำแหน่งที่เหมาะสมใน boot loader Lua เพื่อให้รันไม่ว่าเมนูจะถูกปิดใช้งานหรือไม่
      • พร้อมเปลี่ยนให้รับ EFI entropy 64 ไบต์ แล้วขยายด้วย PBKDF2 ให้ตรงกับอินพุต API 2048 ไบต์ ส่งผลให้เวลา boot ของ FreeBSD arm64/base/UFS ลดจากราว 25 วินาทีเหลือราว 8 วินาที
    • Image ที่ใช้ ZFS บูตนานกว่า UFS และขนาดความหน่วงไม่ได้ขึ้นกับขนาดดิสก์ แต่ขึ้นกับปริมาณข้อมูลบนดิสก์
      • makefs ใส่ทุกอย่างไว้ใน transaction group เดียว และตอน ZFS attach จะไล่ตรวจ transaction group ล่าสุด ทำให้ต้องอ่านและประมวลผล file metadata ทั้งหมดบนดิสก์
      • Mark Johnston แก้ปัญหาโดยทำให้ไฟล์ซิสเต็มบันทึก transaction group ที่สูงกว่า เพื่อไม่ให้ transaction group เดียวถูกมองว่าเป็น “ล่าสุด”
      • เวลาบูตของ ZFS image ลดจากราว 22 วินาทีเหลือราว 11 วินาที
    • หลังเพิ่มการรองรับ IPv6 ให้พอร์ต net/aws-ec2-imdsv2-get ในเดือนธันวาคม 2024 ปัญหาการบูตก็ถูกจับได้อย่างรวดเร็ว
      • พอร์ตนี้ให้ command-line interface สำหรับ EC2 Instance MetaData Service
      • เดิมจะลอง IPv6 ก่อน แต่ค่าตั้งต้นของ IMDS บน instance ยังเป็น IPv4-only และยังคงใช้ TCP timeout เริ่มต้น 75 วินาที
      • หลังแก้ไขจึงเปลี่ยนไปลอง IPv4 ก่อนและลด timeout เหลือ 100ms
  • ยังมีการขยาย FreeBSD AMI flavour ด้วย
    • เดิมมีเพียง base และ cloud-init
    • AMI แบบ small ตัด debug symbol, LLDB, ไลบรารี 32 บิต, FreeBSD tests, Amazon SSM Agent และ AWS CLI ออก ทำให้การใช้พื้นที่ดิสก์ลดจากราว 5GB เหลือราว 1GB
    • AMI แบบ builder ให้ FreeBSD AMI Builder AMIs เพื่อให้ผู้ใช้สร้าง FreeBSD AMI แบบกำหนดเองได้ง่าย
  • เมื่อ snapshot build รายสัปดาห์เพิ่มขึ้นจากการผสมกันของ 4 AMI flavour, 2 file systems, 2 architectures และ 3 เวอร์ชันของ FreeBSD จึงมีการล้าง image เก่าและ EBS snapshot ที่เกี่ยวข้อง
    • บัญชี AWS สำหรับงานวิศวกรรมรีลีสของ FreeBSD ได้รับการสนับสนุนจาก Amazon แต่ค่าใช้จ่ายก็ยังต้องมีคนรับผิดชอบ
    • จึงเขียน shell script ที่ช่วยลบ EBS snapshot ได้ถึง 336TB

งานที่ยังเหลือและข้อจำกัดหลังการสนับสนุนสิ้นสุด

  • นอกเหนือจากโปรเจ็กต์ใหญ่ ยังมีงานเล็กอีกจำนวนมากที่ดำเนินต่อเนื่อง
    • แก้ build ที่พังซึ่งพบจาก snapshot build รายสัปดาห์
    • รีวิวแพตช์ไดรเวอร์ ENA
    • สนับสนุน Dave Cottlehuber ให้เพิ่มความสามารถในการ build OCI Container และอัปโหลดขึ้น repository
    • ปรับปรุงเครื่องมือ bsdec2-image-upload ให้จัดการ internal AWS error ได้อย่างนุ่มนวลขึ้น
    • รายงานประเด็นด้านความปลอดภัยของ AWS ที่พบโดยบังเอิญ
  • หลังการสนับสนุนสิ้นสุด บทบาทหัวหน้าวิศวกรรมรีลีสของ FreeBSD และผู้ดูแลแพลตฟอร์ม FreeBSD/EC2 จะยังคงดำเนินต่อไป
    • FreeBSD 15.0 มีกำหนดมาถึงในเดือนธันวาคม
    • ในปี 2026 จะมี 14.4, 15.1, 14.5 และ 15.2 ตามมา
  • เมื่อเวลาที่ทุ่มได้ลดลง วิธีการแก้ปัญหาโดยตรงก่อนรีลีสจะทำได้ยากขึ้น
    • ฟีเจอร์ที่เข้ามาช้าจะมีแนวโน้มถูกถอดออกมากกว่าจะถูกแก้ให้ทันรีลีส
    • การที่ FreeBSD 14.2 สามารถรวม OCI Containers ได้ เป็นเพราะเวลาที่ได้รับการสนับสนุนทำให้มั่นใจได้ว่าชิ้นส่วนที่จำเป็นทั้งหมดเข้ามาครบถ้วน
  • ฝั่ง EC2 แม้จะมีการทดสอบ regression ของประสิทธิภาพการบูตไว้แล้ว ซึ่งน่าจะช่วยจับปัญหาที่เกี่ยวข้องได้ แต่รายการฟีเจอร์ที่ต้องพัฒนาอาจหยุดนิ่งหากไม่มีเวลาเพิ่ม
    • การขยาย file system อัตโนมัติเมื่อขยาย EBS volume
    • ปรับปรุงการตั้งค่าอัตโนมัติสำหรับ network interface หลายตัวและ network interface hotplug
    • rolling AMI แบบ “pre-patched”
    • เว็บไซต์สำหรับสร้างไฟล์ EC2 user-data เพื่อใช้ติดตั้งแพ็กเกจและรัน daemon เป็นต้น
    • กลับมาทำงานด้าน FreeBSD/Firecracker และยกระดับเป็นแพลตฟอร์มที่รองรับ
  • การสนับสนุนจาก Amazon เป็นโอกาสที่ใหญ่กว่าสิ่งที่นักพัฒนาโอเพนซอร์สส่วนใหญ่ได้รับมาก และแม้จะน่าเสียดายที่การสนับสนุนสิ้นสุดลง ก็ยังคงมีความขอบคุณต่อผลงานที่ทำได้ในช่วงเวลานั้น

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

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

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

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

    • การครอสคอมไพล์ของ Zig ยอดเยี่ยมมาก และก็ดีใจที่ FreeBSD ถูกเพิ่มเข้าไปในรายชื่อเป้าหมายที่รองรับ
    • Zig ใช้ ไลเซนส์ที่เป็นมิตรกับ BSD และ FreeBSD ก็มี LLVM อยู่ในระบบพื้นฐานอยู่แล้ว เลยสงสัยว่าสักวัน Zig จะเข้าไปอยู่ในระบบพื้นฐานด้วยไหม
      ถ้ามีตัวแทนภาษา C ที่ได้รับการยอมรับอย่างเป็นทางการก็คงดี

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

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

  • ฝั่งแล็ปท็อปก็มีงานเยอะ และอ่านมาว่า BSD Foundation ลงทุน 750,000 ดอลลาร์กับเรื่องนี้
    รวมถึงการ implement สิ่งอย่างสถานะประหยัดพลังงาน S0ix และดูโปรเจกต์ได้ที่นี่: https://github.com/FreeBSDFoundation/proj-laptop

    • ใช่ มีงานจำนวนมากกำลังดำเนินอยู่ ผมแค่เขียนถึงงานที่ผมทำอยู่เท่านั้น ;-)

  • นับถือ cperciva จริง ๆ
    ไม่รู้ว่าเขาทำทั้งหมดนี้ไปพร้อมกับ Tarsnap ได้อย่างไร

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

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

    • แน่นอนว่าถ้า Amazon มีส่วนร่วมมากกว่านี้ก็คงดี แต่การไม่อยู่ในรายชื่อผู้บริจาคของ FreeBSD Foundation ไม่ได้แปลว่าไม่ได้สนับสนุน FreeBSD
      ตัวอย่างเช่น เงินที่จ่ายให้ผมไม่ได้ผ่าน Foundation ถ้าให้เดา ในบรรดาการพัฒนา FreeBSD ที่มาจากเงินทุนบริษัท งานที่ได้รับการสนับสนุนผ่าน Foundation น่าจะราว 10%
      10% นั้นสำคัญเพราะสามารถโฟกัสกับ “สิ่งที่ FreeBSD ต้องการ” ไม่ใช่ “สิ่งที่บริษัท X ต้องการ” โดยเฉพาะ แต่ก็ยังเป็นสัดส่วนเล็กอยู่ดี
    • เรื่องนี้ไม่ได้แสดงภาพทั้งหมด
      อย่างแรก มันแสดงแค่สแนปช็อตการบริจาคให้ Foundation ในปีใดปีหนึ่ง ดังนั้นประวัติการบริจาคย่อมไม่ปรากฏ
      อย่างที่สอง มันไม่ได้แสดง การมีส่วนร่วมด้านการพัฒนา ด้วย เรื่องแบบนี้มักดูสรุปได้ใน release notes ของแต่ละรุ่น [1]
      [1] https://www.freebsd.org/releases/
    • สงสัยว่า Microsoft สนับสนุนไปทำไม ส่วนขยาย Hyper-V ก็ไม่ได้สมบูรณ์เท่า Linux และก็ไม่มี พอร์ต .NET ที่ Microsoft รองรับ
      นึกไม่ออกว่าบริการของ Microsoft ไม่ว่าจะเป็นคลาวด์หรือไม่ รันบน *BSD มีอะไรบ้าง
    • Amazon เป็นหนึ่งใน FAANG ที่ทำเพื่อ ซอฟต์แวร์เสรีและโอเพนซอร์ส น้อยที่สุด

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

    • โครงสร้างพื้นฐานของบริษัทและส่วนตัวของผมทั้งหมดใช้ FreeBSD บน FreeBSD Intel NIC เชื่อถือได้ 100% เลยใช้แค่นั้น
      Realtek ดูเหมือนจะพังเมื่อมีโหลด แม้ว่าวิศวกร FreeBSD ที่ดูแลไดรเวอร์จะพยายามอย่างหนักก็ตาม ไม่ได้บ่นนะ และเคารพความพยายามของพวกเขา
      เรื่องนี้เป็นต้นทุนเล็กน้อย และช่วยให้ไม่ต้องติดตั้งระบบปฏิบัติการที่เสถียรน้อยกว่า

  • สมัยราว ๆ FreeBSD 7 หรือ 8 ผมจำได้ว่าไดรเวอร์ FreeBSD สำหรับของอย่าง การ์ด Wi‑Fi Atheros ดีกว่า Linux
    ผมชอบ FreeBSD มากกว่าจนถึงประมาณปี 2021 แต่เปลี่ยนไปเมื่อคอมพิวเตอร์ที่มีคอร์ CPU ต่างชนิดผสมกันเริ่มพบได้ทั่วไป ตอนแรกผมซื้อ RockPro64 ที่มีคอร์ big 2 คอร์กับคอร์ little 4 คอร์ และต่อมาก็ซื้อ Intel Alder Lake
    เท่าที่ผมเข้าใจ scheduler ของ FreeBSD ยังจัดการคอนฟิกแบบนี้ได้ไม่ดีนัก จึงเหมือนพาระบบลงไปอยู่ที่ตัวหารร่วมต่ำสุดตามคอร์ที่ช้ากว่า

  • แค่สงสัยว่า ผู้ใช้หลักของ FreeBSD/EC2 คือใครกัน?

    • ไม่รู้เลย พูดจริง ๆ ผู้ใช้ที่ติดต่อมาหาผมน่าจะเป็นแค่ราว 0.1% ของฐานผู้ใช้ FreeBSD/EC2 ทั้งหมด
      ผมอยากรู้จริง ๆ ว่าใครใช้ FreeBSD บน EC2 บ้าง
    • Netflix ใช้แค่กับอุปกรณ์ edge หรือเปล่า?

  • เป็นบทความที่แสดงให้เห็นได้ดีมากว่า การสนับสนุนโอเพนซอร์ส ขององค์กรทำงานอย่างไร

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

    • ผมเคยทำงานที่บริษัทบริการการเงินซึ่งใช้ FreeBSD ทั้งบน EC2 และบน bare metal ในดาต้าเซ็นเตอร์ที่ดูแลเอง ฟีเจอร์สองอย่างที่ใช้ตลอดคือ ZFS กับ jail
      แต่ละบริการรันอยู่ใน jail ของตัวเองเพื่อการแยกส่วน และเซิร์ฟเวอร์เครื่องเดียวที่ไม่ได้แรงมากก็รันบริการทั้งหมดได้ ทำให้คุ้มค่ามาก
      ถึงจุดหนึ่งเรา migrate ขึ้นคลาวด์เพื่อทำโครงแบบไฮบริด และเมื่อใช้ Linux(k8s) ผสมกับ FreeBSD ค่าใช้จ่ายก็พุ่งขึ้นมาก ในดาต้าเซ็นเตอร์มีข้อเสียคือคุณต้องซื้อและเปลี่ยนดิสก์เอง ต้องรับมือเหตุการณ์อย่างไฟไหม้ และอยู่ในประเทศเดียวเท่านั้น แต่ AWS ให้ multi-region กับฟีเจอร์ดี ๆ หลายอย่าง ซึ่งก็มีราคาตามนั้น
      เราไม่ได้ใช้ ZFS หนักมาก แต่ครั้งหนึ่งมันช่วยชีวิตได้มากเมื่อเผลอลบตารางในฐานข้อมูล production แล้ว rollback กลับไปยัง ZFS snapshot ก่อนหน้าได้ทันที มีข้อมูลสูญหายเล็กน้อย แต่สำหรับแอปพลิเคชันนั้น uptime สำคัญกว่า จึงไม่ใช่ปัญหาใหญ่ ผมจำได้ว่าเราใช้ ZFS กับ backup ด้วย
      ผมใช้ dtrace แก้ปัญหาในสภาพแวดล้อม production อยู่สองสามครั้ง และเมื่อเราเริ่มนำ Linux เข้ามาในกลุ่มเซิร์ฟเวอร์ FreeBSD แต่ละทีมก็เลือก distro ต่างกันไปเองตามธรรมชาติ จนกลายเป็นสวนสัตว์ย่อม ๆ ถ้าใช้ FreeBSD บนเซิร์ฟเวอร์ก็มีแค่สายพันธุ์เดียว
      ผมยังใช้และชอบทั้งสองอย่าง แต่สิ่งที่ผมชอบ FreeBSD มากจริง ๆ คือมันเป็น รูปแบบที่เคอร์เนลกับระบบปฏิบัติการถูกรวมเป็นหนึ่งเดียว
    • จากประสบการณ์ของผม FreeBSD ให้สมดุลที่ดีระหว่างสิ่งที่ OpenBSD กับ NetBSD ให้ความสำคัญตามลำดับ
      ในอดีต FreeBSD ให้ความสำคัญกับ CPU Intel ก่อน ส่วน NetBSD เด่นเรื่องการพอร์ตไปหลายแพลตฟอร์มมากกว่า และแม้ FreeBSD จะมีความปลอดภัยแข็งแรง แต่ OpenBSD โฟกัสเรื่องความปลอดภัยมากกว่า
      การรองรับ ZFS ของ FreeBSD ถือว่าเปลี่ยนเกมได้จริง ๆ ส่วน Nvidia เท่าที่ผมรู้ เพิ่งมีไดรเวอร์ FreeBSD แบบ native ไม่นานมานี้ และเป็นเวลานานที่ต้องอาศัยความสามารถเข้ากันได้กับเคอร์เนล Linux ของ FreeBSD
      กล่าวอีกอย่างคือ FreeBSD ผสมผสานฟีเจอร์ที่ BSD อื่น ๆ มีได้ดี ขณะเดียวกันก็เสถียรมากบนแพลตฟอร์มฮาร์ดแวร์ที่ผมใช้เป็นหลัก
    • FreeBSD นั้น เน้น throughput ในแบบที่ OpenBSD ไม่ใช่อย่างชัดเจน และผมคิดว่า NetBSD ก็ไม่ใช่เช่นกัน
      NetBSD แข่งด้วยความพกพาไปหลายสถาปัตยกรรม และดูเหมือนไม่ได้ใช้เวลามากนักกับการรักษา throughput เครือข่ายให้สูง
      โดยรวม BSD ทุกตัวเปลี่ยนแปลงน้อยกว่ามาก ซึ่งมีทั้งข้อดีข้อเสีย แต่ผมมองว่าเป็นแพลตฟอร์มสำหรับนำไป integrate ที่ดีกว่า
    • FreeBSD ไม่มีปัญหาเรื่องไลเซนส์ จึงมี การรองรับ ZFS ดีกว่า Linux
    • FreeBSD มีฐานผู้ใช้ใหญ่กว่า OpenBSD หรือ NetBSD มาก เทียบกันไม่ได้เลย
      รายการซอฟต์แวร์ก็ใหญ่กว่ามาก และยังใช้เป็นระบบปฏิบัติการเดสก์ท็อปสมัยใหม่ในชีวิตประจำวันได้ด้วย สำหรับอีกสองตัวนั้นพูดแบบนี้ได้ยาก
      ถ้าถามว่าทำไมไม่ใช้ Linux คำตอบคือผมไม่ต้องการ Linux มันถูกผลประโยชน์องค์กรกดทับมากเกินไป