คุณอาจไม่จำเป็นต้องใช้ Yocto และนั่นก็ไม่เป็นไร

• Yocto ไม่ใช่ดิสทริบิวชัน แต่เป็นเครื่องมือสำหรับประกอบ Linux ดิสทริบิวชันของคุณเอง และหากไม่ต้องการการควบคุมระดับนั้น ก็ยากที่จะถือเป็นตัวเลือกเริ่มต้น
• การมีดิสทริบิวชันของตัวเองหมายถึง การดูแลรักษาเอง พร้อมภาระตามกฎระเบียบอย่าง CRA และความรับผิดชอบในการออกอัปเดตความปลอดภัยตลอดอายุผลิตภัณฑ์
• การนำ Yocto มาใช้มาพร้อมเวลาบิลด์หลายชั่วโมง ไดเรกทอรีบิลด์ขนาดเกิน 100GiB เส้นโค้งการเรียนรู้หลายสัปดาห์ และ เลเยอร์ BSP ที่คุณภาพไม่สม่ำเสมอ
• หากต้องการเพียงฐาน Linux ที่มั่นคงสำหรับรันแอปพลิเคชัน Debian และเครื่องมือสร้างอิมเมจอย่าง mkosi, ELBE, debos อาจเพียงพอด้วยงานเฉพาะโครงการที่น้อยกว่ามาก
• Yocto เหนือกว่าเฉพาะเมื่อจำเป็นต้องปรับแต่งหนัก มีข้อจำกัดด้านขนาดหรือเวลาบูต ต้องตัดบางไลเซนส์ออก หรือมีการสนับสนุน Yocto จากผู้ขายที่แข็งแรงเท่านั้น; ถ้ายังไม่แน่ใจ ดิสทริบิวชันที่มีอยู่แล้วมักดีกว่า

---

Yocto คืออะไรจริง ๆ และทำไมจึงมักถูกใช้เป็นตัวเลือกเริ่มต้น

• Yocto ไม่ใช่ “Yocto Linux distribution” แต่เป็นชุดเครื่องมือสำหรับสร้าง Linux ดิสทริบิวชันของคุณเอง
• Yocto Project มีดิสทริบิวชันอ้างอิงชื่อ Poky ซึ่งสร้างจาก bitbake, openembedded-core, meta-yocto
• Yocto ช่วยให้สามารถประกอบระบบ Linux สำหรับงาน embedded ได้อย่างละเอียด
  • คอมไพล์ทั้ง user space ให้ตรงกับ CPU เป้าหมายได้
  • ใช้แพตช์กับคอมโพเนนต์ใดก็ได้
  • เปิดหรือปิดฟีเจอร์ของแต่ละ recipe ได้
  • ตรึงหรือเปลี่ยนทุกเวอร์ชันได้
• ผู้ขาย SoC และพาร์ตเนอร์ฮาร์ดแวร์จำนวนมากมีเลเยอร์ BSP (Board Support Package) พร้อมใช้ ทำให้มีจุดเริ่มต้นที่รันบนฮาร์ดแวร์จริงได้
• การผสมกันของความยืดหยุ่นกับการสนับสนุนจากผู้ขายทำให้ Yocto มักกลายเป็นตัวเลือกเริ่มต้น แต่ถ้าไม่ต้องการการควบคุมมากขนาดนั้น ภาระอาจมากกว่าประโยชน์

ดิสทริบิวชันของตัวเองหมายถึงการดูแลรักษาเอง

• กฎระเบียบอย่าง Cyber Resilience Act (CRA) กำหนดให้ผู้จัดหาผลิตภัณฑ์ต้องดูแลซอฟต์แวร์ที่ส่งมอบให้ปลอดภัยและต้องมีอัปเดตความปลอดภัยตลอดอายุผลิตภัณฑ์
• Yocto รุ่นทั่วไปได้รับการดูแลเพียงประมาณ 7 เดือน จนกว่าจะมีรุ่นถัดไป
• ตั้งแต่ Yocto 5.0 Scarthgap เป็นต้นมา ตามนโยบายปัจจุบันรุ่น LTS จะได้รับอัปเดตได้นานสูงสุด 4 ปี
• Yocto release ประกอบด้วยชุด recipe ของ bitbake พร้อม metadata สำหรับเวอร์ชันที่กำหนด และดิสทริบิวชันอ้างอิง Poky
• ระหว่างช่วงดูแลรักษา ผู้ดูแล Yocto จะใส่การแก้บั๊กและความปลอดภัยให้คอมโพเนนต์และ Poky โดยการแก้คอมโพเนนต์มัก backport มาจาก upstream เวอร์ชันใหม่ล่าสุด
• ในผลิตภัณฑ์จริง มักไม่ได้ใช้ Yocto แบบเดิม ๆ และมักมีการเปลี่ยนแปลงดังนี้
  • ใส่ แพตช์ที่ไม่ใช่แบบง่าย ๆ หรือการแก้ไขภายในกับบางคอมโพเนนต์
  • เพิ่มคอมโพเนนต์ที่ Yocto ไม่มีให้
  • อัปเกรดหรือตรึงเวอร์ชันเพื่อรับการแก้ไขหรือคงสถานะที่ทราบว่าดี
• ทุกครั้งที่มี Yocto maintenance release ต้องตรวจว่าการแก้ไขภายในยัง apply ทับสถานะใหม่ได้อย่างสะอาด
• สำหรับคอมโพเนนต์ที่เพิ่มเองหรือตรึงไว้ ผู้ดูแล Yocto ไม่อาจรู้ได้ จึงต้องตรวจเองว่าคอมโพเนนต์เหล่านั้นยังได้รับการแก้ไขต่อเนื่องหรือไม่
• หากใช้ Poky แทบไม่ต่างจากเดิม ก็ควรกลับมาถามใหม่ว่าจำเป็นต้องใช้ Yocto หรือไม่

Linux kernel และการพึ่งพาผู้ขาย

• Yocto จัดหาและดูแล Linux kernel เป็นส่วนหนึ่งของแต่ละ release แต่ในผลิตภัณฑ์จริงแทบไม่ค่อยใช้โดยไม่แก้ไข
• อย่างน้อยก็มักต้องใส่แพตช์จากผู้ขาย และต้องใช้ kernel ที่ใหม่พอจะมีไดรเวอร์และการแก้ไขที่ต้องการ
• หากนับรวมการติดตาม CVE แล้ว แค่ kernel อย่างเดียวก็เป็นภาระดูแลขนาดใหญ่ ไม่ว่าจะใช้ Yocto หรือไม่
• หากต้องการควบคุมภาระดูแล แนวทางที่แนะนำคือสร้างบน LTS kernel จาก kernel.org และเก็บทุกการเปลี่ยนแปลงไว้ในชุดแพตช์ที่เป็นระเบียบ
• เมื่อต้องตามการแก้ไขความปลอดภัย ก็ย้ายไปยัง stable release ใหม่แล้ว apply ชุดแพตช์ซ้ำ
• kernel.org ดูแล LTS kernel หลายปี ดังนั้นโดยทั่วไปชุดแพตช์จะ apply ได้สะอาด และจะมีงานจริง ๆ ก็ตอนขยับไป LTS release ใหม่
• หลักการเดียวกันนี้ใช้กับ bootloader ตามการตั้งค่าและข้อกำหนดด้านความปลอดภัย และ bootloader ก็มักมีส่วนที่เฉพาะผู้ขายสูงเช่นกัน
• การยึด kernel ที่ผู้ขายให้มาแบบเดิม ๆ มักไม่ใช่แนวทางที่ดี
  • vendor kernel มักล้าหลัง kernel.org หลายปี
  • แทบไม่ได้รับอัปเดต
  • พลาดการแก้ไขความปลอดภัยส่วนใหญ่

ต้นทุนในการใช้ Yocto

• การเลือกสร้างดิสทริบิวชันเองต้องใช้เวลาเชิงวิศวกรรมจริง

• เวลาบิลด์

  • Yocto คอมไพล์แทบทุกอย่างจากซอร์ส
  • แม้แต่การคลีนบิลด์ของอิมเมจที่ไม่ซับซ้อนมากก็ยังใช้เวลา หลายชั่วโมง บนเวิร์กสเตชันที่เร็ว
  • sstate-cache และ DL_DIR ที่ใช้ร่วมกันช่วยให้บิลด์ซ้ำเร็วขึ้น แต่การแก้ recipe เล็กน้อยก็อาจทำให้แคชส่วนใหญ่ใช้ไม่ได้

• ดิสก์และต้นทุน CI

  • ไดเรกทอรีบิลด์ของ Yocto โตเกิน 100GiB ได้อย่างง่ายดาย
  • CI runner ต้องมีสตอเรจเพียงพอและมีวิธีแชร์ sstate ระหว่างงาน
  • การทำมิเรอร์ sstate และ DL_DIR ช่วยลดความเจ็บปวดได้ แต่โครงสร้างพื้นฐานนั้นคุณต้องดูแลเอง

• เส้นโค้งการเรียนรู้

  • มีหลายเรื่องที่ต้องเรียนรู้ เช่น recipe ของ bitbake, layer, dynamic layer, class, override, ไฟล์ bbappend, PACKAGECONFIG, ความต่างระหว่าง DEPENDS กับ RDEPENDS
  • การ onboard วิศวกรเข้าสู่โค้ดเบสของ Yocto ใช้เวลาไม่ใช่แค่ไม่กี่วัน แต่เป็น หลายสัปดาห์

• คุณภาพของเลเยอร์ BSP ที่แตกต่างกันมาก

  • ผู้ขาย SoC บางรายมีเลเยอร์ BSP ที่สะอาดและดูแลดี
  • ผู้ขายรายอื่นอาจตรึง kernel หรือ bootloader ที่เก่า 5 ปี, hardcode recipe เฉพาะเครื่องไว้ในเลเยอร์ที่ไม่ถูกต้อง, และมีเลเยอร์ meta-vendor ที่พังทุกครั้งที่อัปเกรด Poky
  • BSP ที่ดูเหมือนเป็นจุดเริ่มต้นที่ดี อาจกลายเป็นส่วนที่แย่ที่สุดของบิลด์
  • สิ่งเหล่านี้ไม่ใช่เหตุผลว่าทำไมต้องหลีกเลี่ยง Yocto แต่เป็นเหตุผลว่าทำไมต้องตรวจให้แน่ใจก่อนนำมาใช้ว่าคุณต้องการมันจริง ๆ

ทางเลือก: นำดิสทริบิวชันที่ผ่านการพิสูจน์แล้วมาใช้ซ้ำ

• หากต้องการเพียงฐาน Linux ที่มั่นคงสำหรับรันแอปพลิเคชัน ดิสทริบิวชันที่มีอยู่แล้วอย่าง Debian GNU/Linux สามารถแก้ปัญหาส่วนใหญ่แบบเดียวกันได้ โดยลดงานเฉพาะโครงการลงมาก
• ปัจจุบัน Debian มีแพ็กเกจไบนารีประมาณ 70,000 แพ็กเกจ
• สถาปัตยกรรมที่รองรับมีเช่น amd64, i386, arm64, armhf, riscv64, ppc64el
• SoC จำนวนมากน่าจะรัน Debian binary ได้โดยตรงโดยไม่ต้องคอมไพล์ใหม่
• Debian ไม่ได้เป็นแค่ดิสทริบิวชันที่ให้ user space สมัยใหม่พร้อม systemd, udev, dbus
• ใน archive ยังมีองค์ประกอบสำหรับสร้างระบบ Linux ขนาดเล็กแบบ SysV-style init หรือแบบใช้ BusyBox ด้วย
• คุณสามารถเลือกฐานที่บาง ติดตั้งเฉพาะแพ็กเกจที่ผลิตภัณฑ์ต้องใช้ และยังได้ประโยชน์จากงานของผู้ดูแลแพ็กเกจ Debian

โมเดลการดูแลรักษาของ Debian

• Debian stable ได้รับอัปเดตความปลอดภัยจาก Debian Security Team ราว 3 ปี
• หลังจากนั้นโครงการ Debian LTS ที่ขับเคลื่อนโดยชุมชนจะขยายการสนับสนุนต่ออีกราว 2 ปี บนสถาปัตยกรรมทั่วไป
• ในทางปฏิบัติ นั่นทำให้แต่ละ release รองรับได้ราว 5 ปี ใกล้เคียงกับ Yocto LTS แต่มีงานเฉพาะโครงการน้อยกว่ามาก
• หากต้องการรับการแก้ไขล่าสุด ก็เพียงดึงแพ็กเกจ Debian เวอร์ชันล่าสุดมาแล้วสร้างอิมเมจใหม่
• ลักษณะงานนี้ต่างอย่างมากจากฝั่ง Yocto ที่ต้อง backport แพตช์จาก upstream เองหรือคอยตรวจว่าการแก้ไขภายในยัง apply บน maintenance release ได้ต่อเนื่องหรือไม่

วิธีประกอบอิมเมจ embedded

• อิมเมจ embedded ที่อิง Debian ไม่ได้หมายถึงการบูต SoC จาก USB flash drive แล้วรันตัวติดตั้ง Debian
• แต่เป็นการสร้างอิมเมจที่แฟลชได้จากบน build host แล้วเขียนลงอุปกรณ์
• องค์ประกอบที่ต้องมีคือ
  • bootloader ที่มักเฉพาะ SoC เช่น u-boot
  • Linux kernel ที่มักเฉพาะ SoC
  • root filesystem บน user space ของ Linux ที่ดึงจาก Debian โดยตรง
  • เครื่องมือประกอบอิมเมจที่รวมทั้งสามส่วนให้เป็นอิมเมจที่แฟลชได้
• ตัวเลือกทั่วไปของเครื่องมือประกอบอิมเมจคือ mkosi, ELBE, debos
• ทั้งสามเป็นซอฟต์แวร์เสรีและสร้างอิมเมจแบบกำหนดผลลัพธ์ได้ซึ่งสามารถแฟลชลงฮาร์ดแวร์ได้
• งานดูแลรักษาจะลดลงมาก และการอัปเดตส่วนใหญ่จะกลายเป็นการรีเฟรชแพ็กเกจในอิมเมจแบบ apt แทนการเขียน recipe ใหม่

ตัวอย่างการบิลด์ Debian ด้วย debos

• debos อ่าน YAML recipe
• recipe ประกอบด้วยรายการของ action เช่น รันคำสั่ง, สร้าง root filesystem, ติดตั้งแพ็กเกจ Debian จากแหล่งที่กำหนด
• ลำดับงานพื้นฐานมีดังนี้
  • ใช้ aptly รัน local Debian mirror ที่เก็บสำเนาของแพ็กเกจ Debian ทั้งหมดที่ต้องใช้
  • บิลด์ Linux kernel และถ้าจำเป็นก็รวม bootloader เป็นแพ็กเกจ Debian แล้วเพิ่มเข้า mirror
  • สร้าง snapshot ของ mirror และติดแท็ก
  • แท็กนี้จะกลายเป็น release
  • ตั้งค่า debos ให้ใช้ mirror นั้น และเขียน recipe action เพื่อสร้างอิมเมจเป้าหมาย
  • หากต้องการ ให้เก็บ Debian source package และ SBOM (Software Bill of Materials) ของอิมเมจไว้คู่กับอิมเมจ
• การเก็บ source package และ SBOM ช่วยให้ปฏิบัติตามข้อกำหนดการให้ซอร์สของ GPL และข้อกำหนดด้าน bill of materials ของ CRA ได้
• เครื่องมืออย่าง debsbom สามารถสร้าง SBOM จากระบบ Debian ได้โดยตรง

เมื่อใดควรเลือก Yocto

• Yocto เหมาะเมื่อจำเป็นต้องมี ดิสทริบิวชันที่ปรับแต่งอย่างหนัก
  • user space แบบปรับแต่งเอง
  • compile flag แบบปรับแต่งเอง
  • การแก้ไขเชิงลึกต่อคอมโพเนนต์พื้นฐาน
• เหมาะเมื่อมีข้อจำกัดเข้มงวดด้าน ขนาดหรือเวลาในการบูต ที่ดิสทริบิวชันสำเร็จรูปตอบไม่ได้
• เหมาะเมื่อมีข้อจำกัดด้านไลเซนส์ที่ต้องตัดหมวดไลเซนส์ทั่วไปบางอย่างออก
  • บางอุตสาหกรรม เช่น อุปกรณ์การแพทย์ ยานยนต์ และงานกลาโหมบางประเภท จะไม่แจกจ่ายคอมโพเนนต์ GPLv3
  • กลไก INCOMPATIBLE_LICENSE ของ Yocto ทำให้ตัดตระกูลไลเซนส์บางชนิดออกจากทั้งอิมเมจได้ง่าย
  • บนระบบที่อิง Debian ทั่วไป คุณต้องตรวจสอบและลดแพ็กเกจด้วยตัวเอง
• เหมาะเมื่อเส้นทางการสนับสนุนอย่างเป็นทางการของผู้ขาย SoC คือ Yocto และคุณภาพของ BSP แข็งแรง

เมื่อใดควรหลีกเลี่ยง Yocto

• หากต้องการเพียง Linux สมัยใหม่สำหรับติดตั้งและรันแอปพลิเคชัน คุณอาจไม่จำเป็นต้องใช้ Yocto
• หากงบประมาณด้านสตอเรจและหน่วยความจำรองรับอิมเมจแบบ Debian ทั่วไปได้ ข้อดีของ Yocto จะลดลง
  • ตัวอย่างเกณฑ์คือแฟลชระดับหลายร้อย MB และ RAM 256MB ขึ้นไป
• หากผลิตภัณฑ์มีอายุยาวและการพึ่งพา Debian Security Team เหมาะกว่าการดูแลเอง ก็ควรหลีกเลี่ยง Yocto

เมื่อใดควรหลีกเลี่ยง Debian

• หากต้องแก้ไขหรือบิลด์แพ็กเกจ Debian ใหม่จำนวนมาก Debian จะเสียเปรียบ
  • การบิลด์ใหม่เพียงไม่กี่แพ็กเกจยังพอจัดการได้
  • แพ็กเกจที่บิลด์ใหม่แต่ละตัวคือภาระดูแลที่คุณต้องรับเอง
  • หากต้องแพตช์แพ็กเกจ upstream หลายสิบตัว ก็เท่ากับกำลังสร้างงานที่ผู้ดูแล Debian เคยทำแทนคุณขึ้นมาใหม่
  • ในระดับนี้ โมเดล recipe ของ Yocto จัดการได้สะอาดกว่า
• หากต้องใช้ libc ที่ไม่ใช่ glibc เช่น musl หรือ uClibc Debian จะไม่เหมาะ
  • archive หลักของ Debian ใช้ glibc เป็นหลักโดยรวม
  • หากจะเปลี่ยน คุณต้องบิลด์ archive ส่วนใหญ่ขึ้นมาใหม่เอง
• หากต้องการซอฟต์แวร์ที่ใหม่กว่า Debian stable มาก Debian จะเสียเปรียบ
  • backports อาจช่วยได้กับบางแพ็กเกจ
  • หากผลิตภัณฑ์ต้องใช้คอมไพเลอร์หรือ runtime รุ่นใหม่มาก จะขัดกับ Debian stable
  • Debian testing ไม่เหมาะสำหรับ production

หลักคิดในการตัดสินใจและบทสรุป

• การจะใช้ Yocto หรือไม่ควรตัดสินใจอย่างตั้งใจตั้งแต่ช่วงต้นของผลิตภัณฑ์
• นี่คือการเลือกฐานรากที่ย้อนกลับได้ยากหลังจากผลิตภัณฑ์ถูกนำไปใช้งานภาคสนามแล้ว
• หากยังไม่แน่ใจ การเริ่มจากดิสทริบิวชันที่มีอยู่แล้วมักดีกว่า
• ต้นทุนในการย้ายไป Yocto ภายหลังเมื่อมีเหตุผลจริง มักต่ำกว่าการพบกลางโครงการว่าคุณแบกรับงานดูแลหลายปีโดยแทบไม่ได้ประโยชน์จริง
• Yocto เป็นผลงานวิศวกรรมที่ยอดเยี่ยมซึ่งทำให้คุณสร้างระบบ Linux ที่ต้องการได้อย่างแม่นยำ แต่การควบคุมที่แม่นยำนั้นเองจะกลายเป็นปัญหาเมื่อคุณไม่ได้ต้องการมัน
• ตรรกะเดียวกันนี้ใช้ได้เกือบทั้งหมดกับเครื่องมือบิลด์จากซอร์สอื่น ๆ เช่น Buildroot
• ทันทีที่คุณเริ่มประกอบดิสทริบิวชันของตัวเอง คุณก็รับผิดชอบการดูแลรักษาของมันเองด้วย
• ข้อสรุปหลักชัดเจนมาก
  • “ดิสทริบิวชันของตัวเอง” หมายถึง การดูแลรักษาเอง
  • CRA และกฎระเบียบที่คล้ายกันทำให้ต้นทุนนั้นกลายเป็นภาระที่เกิดขึ้นจริง
  • บิลด์ Yocto ที่ถูกแก้ไขหนักไม่ได้สืบทอดการแก้ไขจาก upstream มาแบบฟรี ๆ
  • ทุก maintenance release กลายเป็นงานตรวจทานและทำซ้ำ
  • ดิสทริบิวชันที่มีอยู่แล้วอย่าง Debian ซึ่งทำอิมเมจด้วย mkosi, ELBE, debos รองรับกรณีทั่วไปได้ด้วยแรงงานเฉพาะโครงการที่น้อยกว่ามาก
  • หากต้องควบคุมระบบแบบละเอียดระดับผ่าตัด Yocto คือผู้ชนะ
  • หากไม่ใช่ การเลือก Yocto คือการแก้ปัญหาที่ยังไม่มีอยู่ด้วยวิธีที่ยาวนานและมีราคาแพง

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ถ้าเส้นทางการรองรับอย่างเป็นทางการของผู้ขาย SoC คือ Yocto ก็คิดว่ายังดีกว่าพอร์ต Ubuntu ที่โดยมากคุณภาพต่ำ แม้ BSP จะไม่แข็งแรงมากนักก็ตาม
  พอร์ต Ubuntu ทำให้งานอย่างการรวม RAUC หรือการทำให้ root filesystem เป็นแบบ immutable ยุ่งยากขึ้น ผมเกลียด Yocto กับภาษาถิ่น bash/python ที่ถูกดัดแปลงของมันมาก แต่สุดท้ายก็ยังต้องผูกอยู่กับมัน

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

  • ไม่แน่ใจว่าคล้าย Yocto แค่ไหน แต่แนวทางทั่วไปในการสร้างอิมเมจระบบฝังตัวบน FreeBSD คือ NanoBSD
    https://docs.freebsd.org/en/articles/nanobsd/
  • แม้จะยังไม่ได้ใช้จริงจังในภาคสนาม และมันอาจยังไม่สมบูรณ์เท่า Yocto แต่ใน buildroot ก็มีของดีอยู่พอสมควร
    ผมเคยใช้เป็นหลักในบริบทของ Nerves ซึ่งโดยพื้นฐานแล้ว Nerves คือการผสมกันของ buildroot + fwup + Erlang VM และซอฟต์แวร์สนับสนุน การพัฒนา แพ็กเกจ และปล่อยใช้งานระบบ Embedded Linux ด้วยมันค่อนข้างสะดวก
  • ผมไม่ได้ทำงานกับระบบ Embedded Linux/BSD โดยตรง แต่ในฐานะคนที่เคยใช้ NetBSD แค่ระบบ build อย่าง build.sh ก็ดูจะเพียงพอแล้ว
    คุณสามารถ cross-compile ทั้งเคอร์เนลและ user space ได้ง่าย ๆ ถ้าตอนท้ายต้องเพิ่มแอปพลิเคชันจาก pkgsrc หรือใส่บูตโหลดเดอร์อย่าง u-boot ลงในอิมเมจที่สร้าง ก็อาจต้องมีสคริปต์เพิ่มหน่อย มันอาจไม่ใช่โฟลว์สำเร็จรูปที่ปรับแต่งเข้ากับแอปของคุณได้ทันที แต่ในฐานะฐานตั้งต้นก็ถือว่าใช้ได้
  • NetBSD ถูกออกแบบมาให้ cross-compile ไปยังสภาพแวดล้อมที่มีข้อจำกัดได้ดี และพอจับทางได้แล้วก็ใช้งานสบายพอสมควร

• จากประสบการณ์ที่มีอย่างจำกัดในการเจอความโหดร้ายของฝั่ง embedded มาบ้าง สำหรับงานแบบนี้ NixOS ค่อนข้างเหมาะเลย และเครื่องมือ build ก็ดีกว่า Yocto มาก

  • สงสัยว่าบนอุปกรณ์ ARM ก็เป็นแบบนั้นไหม ผมเข้าใจว่า ecosystem ของ NixOS ยังอาจเร็วเกินไปนิดสำหรับอุปกรณ์พวกนั้น

• พอดีกับที่บริษัทผมเพิ่งเริ่มวางแผนและสร้าง เคอร์เนล Linux และดิสทริบิวชันแบบคัสตอม สำหรับอุปกรณ์ที่ใช้ Rockchip บทความนี้มาได้จังหวะมาก
  BSP ดูเหมือนจะมีส่วนที่ต้องดูแลรักษาเยอะพอสมควร และการใช้ Debian แบบ “ใช้ไปตรง ๆ” ก็ดูจัดการง่ายกว่างาน bitbake ที่ผมเขียนแบบเละเทะเองมาก ถึงอย่างนั้น ecosystem ของ Yocto เองก็ค่อนข้างดี และมีเครื่องมืออย่าง kas หรือ isar ที่ช่วยให้เริ่มต้นง่ายขึ้น

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