กูเกิลไม่ปล่อยให้ 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