โปรเจกต์ระบบปฏิบัติการ Redox ได้เปิดเผยแผนงานที่ทะเยอทะยานสำหรับปี 2025/26 ซึ่งรวมถึงแนวทางที่น่าสนใจในการแก้ปัญหาหนึ่งในความท้าทายที่ใหญ่ที่สุดที่ระบบปฏิบัติการทางเลือกต้องเผชิญ: การสนับสนุนไดรเวอร์ฮาร์ดแวร์ แทนที่จะพอร์ตไดรเวอร์อุปกรณ์หลายพันตัว ทีม Redox วางแผนที่จะรันระบบ Linux แบบเบาภายใน QEMU เพื่อจัดการไดรเวอร์สำหรับอุปกรณ์ฮาร์ดแวร์ที่หาได้ยากและรุ่นเก่า
สถาปัตยกรรมไดรเวอร์ปฏิวัติสร้างความสนใจในชุมชน
กลยุทธ์ไดรเวอร์ที่เสนอนี้ได้รับความสนใจอย่างมากจากชุมชนเทคโนโลยี แนวทางนี้เกี่ยวข้องกับการพอร์ต QEMU ไปยัง Redox จากนั้นรัน Linux distribution แบบมินิมอลภายในนั้นโดยเฉพาะเพื่อให้การสนับสนุนไดรเวอร์อุปกรณ์ วิธีนี้สร้างอินเทอร์เฟซที่ปลอดภัยระหว่าง Redox และระบบ Linux guest ซึ่งอาจให้ความปลอดภัยที่เหมาะสมพร้อมทั้งขยายความเข้ากันได้ของฮาร์ดแวร์อย่างมาก
สมาชิกชุมชนได้สังเกตว่าเทคนิคนี้ไม่ใช่สิ่งที่ไม่เคยมีมาก่อนอย่างสิ้นเชิง แนวทางที่คล้ายกันได้ถูกใช้กับ USB-to-serial adapters และ Windows XP guests บนระบบ Linux รุ่นใหม่ แนวคิดนี้สร้างขึ้นจากเทคโนโลยีที่มีอยู่แล้วเช่น PCI และ USB passthrough ที่ใช้งานใน QEMU และ Xen พร้อมกับงานที่เกี่ยวข้องในพื้นที่ SR-IOV และ IOMMU
สมาชิกชุมชนคนหนึ่งชี้ให้เห็นว่า HarmonyOS NEXT ได้ใช้งานสิ่งที่คล้ายกันสำหรับการสนับสนุนไดรเวอร์ในโทรศัพท์ที่ใช้งานจริงแล้ว ซึ่งแสดงให้เห็นว่าแนวทางนี้มีความเป็นไปได้ในโลกแห่งความจริง
สภาพแวดล้อมการพัฒนาแบบ Self-Hosting ได้รับความสำคัญเป็นอันดับแรก
นอกเหนือจากนวัตกรรมไดรเวอร์แล้ว Redox กำลังผลักดันอย่างหนักเพื่อให้กลายเป็น self-hosting ซึ่งจะช่วยให้นักพัฒนาสามารถสร้างและรันโค้ดได้โดยตรงบน native kernel นี่เป็นความก้าวหน้าที่สำคัญซึ่งจะทำให้การพัฒนาเร็วขึ้นและสะดวกสบายมากขึ้นสำหรับผู้ร่วมพัฒนา
ความพยายามในการ self-hosting เผชิญกับความท้าทายทางเทคนิคหลายประการ รวมถึงการปรับปรุงประสิทธิภาพเครือข่ายผ่านการใช้งาน ring buffer การย้ายไปใช้ Rust compiler upstream และการเพิ่มความน่าเชื่อถือของ Cargo และ Rust toolchain บน Redox ทีมยอมรับว่า compilers และ build systems ทำหน้าที่เป็นการทดสอบที่หนักหน่วงสำหรับระบบปฏิบัติการ โดยสร้างกระบวนการมากมายและทำการดำเนินการไฟล์อย่างเข้มข้น
ลำดับความสำคัญทางเทคนิคหลักสำหรับปี 2025/26
การพัฒนา Self-Hosting:
- การปรับปรุงประสิทธิภาพเครือข่ายด้วย ring buffers
- การรวม upstream Rust compiler
- ความน่าเชื่อถือของ Cargo และระบบ build
- บริการระบบไฟล์ VirtIO-S สำหรับการเข้าถึง host
จุดเน้นการสนับสนุนฮาร์ดแวร์:
- การปรับปรุง ACPI และการจัดการ firmware
- การพัฒนา stack ไดรเวอร์ WiFi
- การเพิ่มประสิทธิภาพไดรเวอร์ USB และ I2C
- คุณสมบัติ IOMMU และ virtualization
การนำระบบความปลอดภัยมาใช้:
- ระบบความปลอดภัยแบบ capability-based
- การแทนที่ file descriptor ด้วย capabilities
- ข้อจำกัดของ resource namespace
- ชั้นความเข้ากันได้แบบ POSIX-style
ความปลอดภัยและความเข้ากันได้ยังคงเป็นจุดสำคัญหลัก
แผนงานเน้นย้ำถึงความมุ่งมั่นของ Redox ต่อความปลอดภัยแบบ capability-based พร้อมแผนที่จะแทนที่การแสดงผล file descriptor พื้นฐานด้วย capabilities ในช่วง 12 เดือนข้างหน้า การเปลี่ยนแปลงพื้นฐานนี้จะช่วยให้สามารถควบคุมการเข้าถึงทรัพยากรได้อย่างละเอียดมากขึ้นและมีความสามารถในการ sandboxing ที่ดีขึ้น
อย่างไรก็ตาม สมาชิกชุมชนบางคนได้แสดงความกังวลเกี่ยวกับการตัดสินใจที่จะทำให้ libc เป็นอินเทอร์เฟซระบบหลัก นักวิจารณ์โต้แย้งให้มี stable syscall API แบบ Linux มากกว่า หรืออย่างน้อยก็ thin wrapper รอบ syscalls แทนที่จะพึ่งพา compatibility layers อย่างหนัก
รูปแบบการพัฒนา Redox OS
รูปแบบ | กรณีการใช้งานเป้าหมาย | คุณสมบัติหลัก |
---|---|---|
Hosted Runtime | เว็บเซอร์วิสใน VM | โฮสต์ Linux , QEMU/KVM , รองรับ VirtIO-S |
Server Edition | การปรับใช้ Edge/Cloud | Bare metal , คอนเทนเนอร์แบบหลายผู้เช่า , แซนด์บ็อกซ์น้ำหนักเบา |
Desktop Edition | ระบบปฏิบัติการสำหรับใช้งานประจำวัน | COSMIC Desktop , รองรับ Wayland , แซนด์บ็อกซ์โดยค่าเริ่มต้น |
Desktop และ Server Variants มุ่งเป้าไปยังตลาดที่แตกต่างกัน
Redox กำลังพัฒนาไปตามเส้นทางที่แตกต่างกันสามทาง: hosted web services runtime, bare-metal server solution และ desktop environment Desktop variant มีเป้าหมายที่จะสนับสนุน COSMIC Desktop environment ซึ่งต้องการการใช้งาน Wayland support และ GPU acceleration ผ่านเทคโนโลยีเช่น virglrenderer
แนวทาง server มุ่งเน้นไปที่การให้ secure, lightweight sandboxing สำหรับ web services, databases และ applications นี่เป็นสิ่งที่ทีมพิจารณาว่าเป็นการใช้งานที่มีคุณค่าที่สุดสำหรับ Redox โดยเฉพาะใน edge computing และในที่สุดก็ multi-tenant cloud scenarios
แผนงานที่ทะเยอทะยานนี้แสดงให้เห็นถึงวิวัฒนาการของ Redox จากโปรเจกต์ทดลองไปสู่ระบบปฏิบัติการทางเลือกที่อาจใช้งานได้จริง แม้ว่าจะยังมีความท้าทายในด้านต่างๆ เช่น การสนับสนุน WiFi ความเข้ากันได้ของ USB และฟีเจอร์การเข้าถึง แต่กลยุทธ์ไดรเวอร์ที่เป็นนวัตกรรมนี้อาจช่วย Redox ก้าวผ่านอุปสรรคที่สำคัญที่สุดในการยอมรับที่ระบบปฏิบัติการทางเลือกต้องเผชิญ
อ้างอิง: Development Priorities for 2025/26