ในความสำเร็จทางเทคนิคที่โดดเด่น นักพัฒนาได้คอมไพล์และรัน Linux kernel แบบเนทีฟใน WebAssembly (Wasm) ได้สำเร็จ โดยข้ามเลเยอร์การจำลอง CPU แบบดั้งเดิม วิธีการนี้สัญญาว่าจะได้ประสิทธิภาพใกล้เคียงกับระบบเนทีฟสำหรับการรัน Linux distribution เต็มรูปแบบโดยตรงในเว็บเบราว์เซอร์ แม้ว่าการทดสอบในระยะแรกจะเผยให้เห็นทั้งความเร็วที่น่าประทับใจและปัญหาความเสถียรที่สำคัญซึ่งเน้นย้ำถึงลักษณะการทดลองของโครงการนี้
ความก้าวหน้าด้านประสิทธิภาพด้วยสถาปัตยกรรม WebAssembly
การทดสอบเบื้องต้นจากชุมชนเผยให้เห็นการปรับปรุงประสิทธิภาพอย่างมากเมื่อเทียบกับตัวจำลอง Linux แบบดั้งเดิมในเบราว์เซอร์ บรรทัดฐานเบื้องต้นแสดงให้เห็นว่าระบบ Linux ที่คอมไพล์ด้วย Wasm ทำได้ดีกว่าเซ็ตอัพการจำลองก่อนหน้าซึ่งทำได้เพียงประมาณ 200 MIPS ผู้ใช้รายหนึ่งที่รันการคำนวณทางคณิตศาสตร์ด้วย 'bc -lq' รายงานเวลาการดำเนินการที่เร็วขึ้นอย่างมาก ชี้ให้เห็นว่าวิธีนี้อาจปฏิวัติวิธีการรันแอปพลิเคชันที่ซับซ้อนในสภาพแวดล้อมเบราว์เซอร์
การคอมไพล์ด้วยสถาปัตยกรรม WASM นี้ทำลายการตั้งค่าการจำลองแบบเก่าของฉันไปอย่างสิ้นเชิง ซึ่งทำได้เพียงประมาณ 200 MIPS บางทีวิธีการนี้อาจสามารถทำให้เป็นแบบทั่วไปได้ การรัน Linux distribution เต็มรูปแบบด้วยความเร็วใกล้เคียงเนทีฟตรงในเบราว์เซอร์คงจะยอดเยี่ยมมาก
การเพิ่มขึ้นของประสิทธิภาพเกิดจากการกำจัดเลเยอร์การแปลคำสั่ง CPU แบบดั้งเดิม ไม่เหมือนกับโปรเจกต์ที่จำลองสถาปัตยกรรม CPU ทั้งหมดเช่น x86 หรือ RISC-V การนำไปใช้นี้คอมไพล์ทุกไบนารีโดยตรงไปยัง WebAssembly โดยแต่ละกระบวนการ Linux ทำงานเป็น Web Worker แยกจากกัน ความแตกต่างทางสถาปัตยกรรมนี้หมายความว่าแอปพลิเคชันยูสเซอร์สเปซได้รับประโยชน์จากการคอมไพล์โดยตรงไปยัง Wasm ในขณะที่ยังคงมีการเข้าถึง Linux kernel API เต็มรูปแบบ แทนที่จะเป็นชิมขั้นต่ำที่จัดให้โดยสภาพแวดล้อมเช่น Emscripten
การเปรียบเทียบประสิทธิภาพ:
- การจำลองแบบดั้งเดิม (jor1k): ~200 MIPS
- การจำลอง RISC-V (WebCM): ~500 MIPS
- Native WebAssembly Linux: สูงกว่าทั้งสองแบบอย่างมีนัยสำคัญ (รอผลการทดสอบที่แน่นอน)
ความท้าทายด้านความเสถียรและข้อจำกัดของระบบ
แม้จะมีความสำเร็จด้านประสิทธิภาพ ผู้ใช้ก็ค้นพบปัญหาความเสถียรมากมายอย่างรวดเร็วระหว่างการทดสอบ คำสั่งการดูแลระบบพื้นฐานเช่น 'du -h' และ 'wget' มักทำให้ WebAssembly แตกด้วยข้อผิดพลาดการเข้าถึงหน่วยความจำและข้อผิดพลาดคำสั่งที่ไม่ถูกต้อง คำสั่ง 'ping' ล้มเหลวทั้งหมดเนื่องจากไม่สามารถสร้าง raw socket ได้ ซึ่งเน้นย้ำข้อจำกัดด้านเครือข่ายที่มีอยู่ในสภาพแวดล้อมเบราว์เซอร์ ผู้ทดสอบรายหนึ่งรายงานว่าการเซสชันของพวกเขาสิ้นสุดลงอย่างกะทันหันด้วยข้อความ kernel panic หลังจากพยายามตรวจสอบการใช้งานดิสก์
เอกสารประกอบของโครงการรับทราบปัญหาที่ทราบแล้วหลายประการ รวมถึงบั๊กแปลกๆ ในระบบ build ของ LLVM ที่ต้องการ build คอมไพเลอร์ทุกครั้งที่สองเพื่อให้สำเร็จ นอกจากนี้ยังมีข้อจำกัดที่ป้องกันการใช้ช่องว่างในเส้นทางไฟล์เมื่อสร้างส่วนประกอบ Linux kernel ความแปลกประหลาดเหล่านี้เน้นย้ำลักษณะการทดลองของการรันระบบปฏิบัติการเต็มรูปแบบในสภาพแวดล้อมที่แตกต่างโดยพื้นฐานจากฮาร์ดแวร์แบบดั้งเดิม
ข้อจำกัดที่ทราบแล้ว:
- ไม่รองรับ MMU (ต้องใช้การกำหนดค่า kernel แบบ NOMMU)
- ไม่มีการใช้งาน Network sockets
- Path ไม่สามารถมีช่องว่างระหว่างการ build
- ปัญหา race condition ของระบบ build ของ LLVM ต้องใช้การ build แบบสลับกัน
ศักยภาพทางการศึกษาและแอปพลิเคชันในอนาคต
สมาชิกในชุมชนตระหนักถึงคุณค่าทางการศึกษาทันทีที่ได้มีสภาพแวดล้อม Linux ที่ทำงานได้และเข้าถึงได้ผ่านเว็บเบราว์เซอร์สมัยใหม่ใดๆ ความสามารถในการทดสอบ Linux distribution หรือซอฟต์แวร์เฉพาะโดยไม่ต้องดาวน์โหลด ทำให้สิ่งนี้มีคุณค่าอย่างยิ่งสำหรับการตั้งค่าทางการศึกษา โดยเฉพาะบนอุปกรณ์ที่มีข้อจำกัดเช่น Chromebook ความรวดเร็วในการตอบสนองและข้อกำหนดการตั้งค่าที่น้อยที่สุดของโครงการอาจลดอุปสรรคสำหรับผู้ที่กำลังเรียนรู้การจัดการระบบ Linux หรือการทดลองใช้เครื่องมือ command-line
ผู้แสดงความคิดเห็นหลายคนแสดงความตื่นเต้นเกี่ยวกับศักยภาพในการสร้างสภาพแวดล้อม Linux ที่ปรับแต่งเองด้วยแอปพลิเคชันเฉพาะที่ติดตั้งไว้ล่วงหน้า ระบบ build แบบ Docker ที่กล่าวถึงในเอกสารประกอบโครงการ อาจสามารถขยายออกไปเพื่อสร้าง image Linux Wasm ที่ปรับแต่งแล้วซึ่งมีเครื่องมือหรือสภาพแวดล้อมการพัฒนาที่เฉพาะเจาะจง สิ่งนี้จะเปิดใช้งานสถานการณ์ที่ผู้ใช้สามารถเข้าถึงเครื่องมือ Linux เฉพาะทางได้ทันทีผ่านเบราว์เซอร์ของพวกเขาโดยไม่ต้องมีการติดตั้งในเครื่อง
สถาปัตยกรรมทางเทคนิคและการจัดการหน่วยความจำ
สถาปัตยกรรมของโครงการเผยให้เห็นโซลูชันที่สร้างสรรค์สำหรับข้อจำกัดของ WebAssembly เนื่องจาก Wasm ขาด Memory Management Unit (MMU) Linux kernel ต้องถูกคอมไพล์ในการกำหนดค่า NOMMU ซึ่งต้องการให้โปรแกรมถูก build ด้วยแฟล็ก position-independent code แต่ละเธรด Linux ถูกแมปไปยัง Web Worker ในเบราว์เซอร์ ซึ่งอนุญาตให้มี CPU พร้อมกันได้สูงสุดถึง 8,000 ตัว โดยใช้ประโยชน์จากการสนับสนุนของ Linux สำหรับคอร์โปรเซสเซอร์จำนวนมาก
โมเดลเธรดนี้นำเสนอทั้งข้อได้เปรียบและข้อจำกัด แม้ว่าหน่วยความจำจะไม่สามารถแชร์ระหว่างกระบวนการได้ในความหมายดั้งเดิม แต่การแยกนี้ให้ประโยชน์ด้านการป้องกันหน่วยความจำโดยธรรมชาติ การนำไดรเวอร์คอนโซล์ไปใช้แสดงให้เห็นว่าไดรเวอร์อุปกรณ์สามารถเชื่อมต่อสภาพแวดล้อม WebAssembly ไปยัง JavaScript ได้อย่างไร ชี้ให้เห็นว่าฟังก์ชันการทำงานของเครือข่ายสามารถเพิ่มได้ผ่านการนำไดรเวอร์ที่คล้ายกันซึ่งส่งออกแพ็กเก็ตเครือข่ายไปยัง JavaScript เพื่อจัดการ
คอมโพเนนต์ซอฟต์แวร์หลักและเวอร์ชัน:
- LLVM Project: 18.1.2 (พร้อมการรองรับ linker script ของ wasm-ld)
- Linux Kernel: 6.4.16 (พร้อม patches สำหรับสถาปัตยกรรม Wasm)
- musl libc: 1.2.5 (พร้อมการรองรับ target Wasm)
- BusyBox: 1.36.1 (พร้อม defconfig สำหรับ Wasm)
การเปรียบเทียบกับแนวทางทางเลือก
ชุมชนเปรียบเทียบแนวทาง WebAssembly แบบเนทีฟนี้อย่างรวดเร็วกับวิธีการทางเลือกเช่น container2wasm ซึ่งแปลงคอนเทนเนอร์เป็น Wasm โดยใช้เลเยอร์การจำลองเช่น Bochs หรือ TinyEMU แม้ว่าโซลูชันเหล่านั้นจะสนับสนุนการรันไบนารีที่มีอยู่โดยไม่ต้องคอมไพล์ใหม่ แต่พวกมันก็ได้รับผลกระทบด้านประสิทธิภาพจากการแปลคำสั่ง CPU แนวทางการคอมไพล์แบบเนทีฟนี้อาจให้ประสิทธิภาพที่ดีขึ้นอย่างมีนัยสำคัญ แต่ต้องการการสร้างส่วนประกอบซอฟต์แวร์ทั้งหมดใหม่โดยเฉพาะสำหรับเป้าหมาย WebAssembly
โปรเจกต์อื่นๆ เช่น jor1k และ WebCM แสดงให้เห็นว่าการจำลอง RISC-V ที่มีความสามารถสามารถทำความเร็วได้สูงถึง 500 MIPS ในเบราว์เซอร์ แต่แนวทาง Wasm แบบเนทีฟดูเหมือนจะอยู่ในตำแหน่งที่จะเกินตัวเลขเหล่านี้อย่างมากเมื่อความเสถียรดีขึ้น การแลกเปลี่ยนระหว่างความเข้ากันได้และประสิทธิภาพมีแนวโน้มที่จะกำหนดว่าแนวทางใดจะกลายเป็นแนวทางหลักสำหรับกรณีการใช้งานที่แตกต่างกัน
บทสรุป
การนำ Linux ไปใช้แบบเนทีฟใน WebAssembly ที่สำเร็จ แม้จะมีบั๊ก แสดงถึงจุดหมายสำคัญในเทคโนโลยีเว็บ แม้ว่าในปัจจุบันจะเหมาะสมหลักสำหรับการทดลองและการศึกษา แต่อรรถาธิบายประสิทธิภาพชี้ให้เห็นถึงอนาคตที่แอปพลิเคชันที่ซับซ้อนและแม้แต่สภาพแวดล้อมการพัฒนาที่สมบูรณ์สามารถทำงานได้อย่างมีประสิทธิภาพในเบราว์เซอร์ เมื่อมาตรฐาน WebAssembly พื้นฐานวิวัฒนาการและการนำไปใช้ในระยะแรกเหล่านี้เติบโตเต็มที่ เราอาจเห็นสภาพแวดล้อม Linux แบบเบราว์เซอร์กลายเป็นเครื่องมือที่ใช้งานได้จริงแทนที่จะเป็นสิ่งน่าสงสัยทางเทคโนโลยี การทดสอบและการรายงานบั๊กอย่างกระตือรือร้นของชุมชนจะเร่งกระบวนการพัฒนานี้อย่างไม่ต้องสงสัย นำเราเข้าใกล้วิสัยทัศน์ของการคำนวณแบบพกพาได้จริงและเป็นอิสระจากแพลตฟอร์ม