กูเกิลไม่ปล่อยให้ Adobe สร้างความตื่นเต้นให้กับนักพัฒนาภาษา C/C++ ด้วย Alchemy ไปล่วงหน้านานนัก ด้วยการปล่อย Native Client ปลั๊กอินสำหรับการพัฒนาซอฟต์แวร์แบบ native code หรือการปล่อยชุดคำสั่งให้ลงไปยังซีพียูตรงๆ แต่ยังได้ความปลอดภัยแบบเดียวกับการใช้ปลั๊กอินตามปรกติ โดยสรุปเป็นดังนี้
- ซอฟต์แวร์ทั้งหมดจะถูกคอมไพล์เป็นไฟล์คำสั่ง x86 (ภาษาเครื่อง) ตรงๆ
- โค้ดที่จะถูกปล่อยลงซีพียูจะถูกตรวจสอบล่วงหน้า ด้วยคำสั่ง inner-sandbox เพื่อป้องกันไม่ให้ไปแก้ไขสิ่งที่ไม่ได้รับอนุญาต รวมถึงการแก้ไขโค้ดของตัวเองด้วย
-
หลังจากนั้นจะมีการตรวจสอบอีกชั้น ไม่ให้มีการเรียก system-call ของระบบปฏิบัติการโดยตรง แต่ต้องเรียกผ่าน Native Client ทั้งหมด
ทั้งสองเทคโนโลยีมีข้อต่างกันอยู่หลายประการ ผมสรุปๆ มาคร่าว
-
Native Client นั้นในตอนนี้ผูกติดกับเครื่องที่เป็น x86 เท่านั้น กูเกิลระบุว่ากำลังพัฒนาส่วน ARM และ PPC อยู่ ส่วน Alchemy นั้นทำงานได้ทุกแพลตฟอร์มที่มี Flash 10 ซึ่งตอนนี้เหมือนจะยังมีเฉพาะ x86 เหมือนกัน
- หลังจากโค้ดได้รับการตรวจสอบแล้ว Native Client จะทำงานที่ความเร็วเครื่อง ส่วน Alchemy นั้นทำงานบน Virtual Machine ตลอดเวลา
- Native Client เป็นโอเพนซอร์สใช้สัญญาอนุญาตแบบ New BSD (แทบไม่มีเงื่อนไขอะไรเลย)
- Flash นั้นรันเป็นโปรเซสดียวกันทุกหน้าต่าง ทุกช่อง แต่ Native Client นั้นทุก instance เป็นโปรเซสแยกกันทั้งหมด เนื่องจากข้อจำกัดเวลาเกิด Exception จากฮาร์ดแวร์ที่ไม่สามารถดักเอาไว้ได้
- ในรายงานการวิจัย (PDF) ของ Native Client ระบุว่าแม้ว่าขนาดไฟล์ที่คอมไพล์แล้วจะใหญ่กว่ามาก แต่ความเร็วนั้นตกลงไปไม่เกิน 10% ใน SPEC2000
- ทีมงานลองพอร์ตโค้ด H.264 ความยาว 11,000 บรรทัดมาบน Native Client พบว่าต้องแก้โค้ดทั้งหมดประมาณ 20 บรรทัด กว่าครึ่งเป็นปัญหาคอมไพล์ไม่ผ่าน อันนี้ชนกับ Alchemy แน่นอนเพราะตัวนั้นใช้ Ogg Theora มาเดโมว่าพอร์ตได้
- ทั้งสองอันเดโมด้วย Quake เหมือนกัน ท่าทางจะพยายามชิงตลาดจาก ActiveX ให้ได้ในเร็ววัน
เท่าที่อ่านดูแล้ว Native Client ยังห่างไกลจากระดับใช้งานจริงอยุ่มาก การเปิดตัวครั้งนี้คงเป็นการดึงนักพัฒนาเอาไว้ไม่ให้เทใจไปให้ Alchemy หมด โดยการบอกว่า "กู(เกิล)ก็มีเหมือนกัน"
ที่มา - Google Code Blog, Google Security Blog, Native Client