src/native_client_sdk/src/doc/faq.rst

   1 ##########################
   2 Frequently Asked Questions
   3 ##########################
   4
   5 .. contents::
   6   :local:
   7   :backlinks: none
   8   :depth: 2
   9
  10 This document answers some frequently asked questions about Native
  11 Client (NaCl) and Portable Native Client (PNaCl, pronounced
  12 "pinnacle"). For a high-level overview of Native Client, see the
  13 :doc:`Technical Overview <overview>`.
  14
  15 If you have questions that aren't covered in this FAQ:
  16
  17 * Scan through the :doc:`Release Notes <sdk/release-notes>`.
  18 * Search through or ask on the :doc:`Native Client Forums <help>`.
  19
  20
  21 What is Native Client Good For?
  22 ===============================
  23
  24 Why did Google build Native Client?
  25 -----------------------------------
  26
  27 * **Performance:** Native Client modules run nearly as fast as native
  28   compiled code.
  29 * **Security:** Native Client lets users run native compiled code in the
  30   browser with the same level of security and privacy as traditional web
  31   applications.
  32 * **Convenience:**
  33
  34   * Developers can leverage existing code, written in C/C++ or other
  35     languages, in their applications without forcing users to install a
  36     plugin.
  37   * This code can interact with the embedding web page as part of an
  38     HTML and JavaScript web application, or it can be a self-contained
  39     and immersive experience.
  40
  41 * **Portability:** Native Client and Portable Native Client applications
  42   can execute on:
  43
  44   * The Windows, Mac, Linux or ChromeOS operating systems.
  45   * Processors with the x86-32, x86-64, or ARM instruction set
  46     architectures. Native Client also has experimental support for MIPS.
  47
  48 Portable Native client further enhances the above:
  49
  50 * **Performance:** Each PNaCl release brings with it more performance
  51   enhancements. Already-released applications get faster over time,
  52   conserving user's battery.
  53 * **Security:** Users are kept secure with an ever-improving sandbox
  54   model which adapts to novel attacks, without affecting
  55   already-released applications.
  56 * **Convenience:** Developers only need to ship a single ``.pexe`` file,
  57   not one ``.nexe`` file per supported architecture.
  58 * **Portability:** Developers and users don't need to worry about
  59   already-released applications not working on new hardware: PNaCl
  60   already supports all architectures NaCl does, and as PNaCl evolves it
  61   gains support for new processors and fully uses their capabilities.
  62
  63 .. TODO Expand on the PNaCl performance section in another document, and
  64 .. link to it here. How does one profile PNaCl code? What are common
  65 .. causes of slowness? How can code be made faster? What's the best way
  66 .. to use Pepper's asynchronous APIs? What do I need to know about
  67 .. threads and inter-thread communications? Can I use SIMD or other
  68 .. processor-specific instructions? What about the GPU?
  69
  70 For more details, refer to the :doc:`history behind and comparison of
  71 NaCl and PNaCl <nacl-and-pnacl>`.
  72
  73 When should I use Portable Native Client instead of Native Client?
  74 ------------------------------------------------------------------
  75
  76 See :doc:`NaCl and PNaCl <nacl-and-pnacl>`. In short: PNaCl works on the Open
  77 Web platform delivered by Chrome whereas NaCl only works on the Chrome Web
  78 Store.
  79
  80 When should I use Portable Native Client / Native Client?
  81 ---------------------------------------------------------
  82
  83 The following are some typical use cases. For details, see the
  84 :doc:`Technical Overview <overview>`.
  85
  86 * Porting existing applications or software components, written in C/C++ or
  87   virtual machines written in C/C++, for use in a web application.
  88 * Using compute-intensive applications, including threads and SIMD, such as:
  89
  90   * Scientific computing.
  91   * Handling multimedia for a web application.
  92   * Various aspects of web-based games, including physics engines and AI.
  93
  94 * Running untrusted code on a server or within an application (such as a plugin
  95   system for a game).
  96
  97 Portable Native Client and Native Client are versatile technologies which are
  98 used in many other contexts outside of Chrome.
  99
 100 How fast does code run in Portable Native Client?
 101 -------------------------------------------------
 102
 103 Fast! The SPEC2k benchmarks (C, C++ and floating-point benchmarks) give
 104 the following overhead for optimized PNaCl compared to regular optimized
 105 LLVM:
 106
 107 +--------+-----+
 108 | x86-32 | 15% |
 109 +--------+-----+
 110 | x86-64 | 25% |
 111 +--------+-----+
 112 |  ARM   | 10% |
 113 +--------+-----+
 114
 115 Note that benchmark performance is sometimes bimodal, so different use
 116 cases are likely to achieve better or worse performance than the above
 117 averages. For example floating-point heavy code usually exhibits much
 118 lower overheads whereas very branch-heavy code often performs worse.
 119
 120 Note that PNaCl supports performance features that are often used in
 121 native code such as :ref:`threading <language_support_threading>` and
 122 :ref:`Portable SIMD Vectors <portable_simd_vectors>`.
 123
 124 For details, see:
 125
 126 * `PNaCl SIMD: Speed on the Web`_.
 127 * `Adapting Software Fault Isolation to Contemporary CPU Architectures`_ (PDF).
 128 * `Native Client: A Sandbox for Portable, Untrusted x86 Code`_ (PDF).
 129
 130 If your code isn't performing as close to native speed as you'd expect,
 131 :doc:`let us know <help>`!
 132
 133 .. TODO Link to the non-existent performance page! (see above todo).
 134
 135 Why use Portable Native Client instead of *<technology X>*?
 136 -----------------------------------------------------------
 137
 138 Many other technologies can be compared to Portable Native Client:
 139 Flash, Java, Silverlight, ActiveX, .NET, asm.js, etc...
 140
 141 Different technologies have different strengths and weaknesses. In
 142 appropriate contexts, Portable Native Client can be faster, more secure,
 143 and/or more compatible across operating systems and architectures than
 144 other technologies.
 145
 146 Portable Native Client complement other technologies by giving web
 147 developers a new capability: the ability to run fast, secure native code
 148 from a web browser in an architecture-independent way.
 149
 150 If I want direct access to the OS, should I use Native Client?
 151 --------------------------------------------------------------
 152
 153 No---Native Client does not provide direct access to the OS or devices,
 154 or otherwise bypass the JavaScript security model. For more information,
 155 see later sections of this FAQ.
 156
 157
 158 Development Environments and Tools
 159 ==================================
 160
 161 What development environment and development operating system do you recommend?
 162 -------------------------------------------------------------------------------
 163
 164 You can develop on Windows, Mac, or Linux, and the resulting Native Client or
 165 Portable Native Client application will run inside the Google Chrome browser on
 166 all those platforms as well as ChromeOS. You can also develop on ChromeOS with
 167 Crouton_ or our `experimental development environment which runs within NaCl`_,
 168 and we're working on self-hosting a full development environment on Portable
 169 Native Client.
 170
 171 Any editor+shell combination should work as well as IDEs like Eclipse,
 172 Visual Studio with the :doc:`Native Client Add-In
 173 <devguide/devcycle/vs-addin>` on Windows, or Xcode on Mac OSX.
 174
 175 I'm not familiar with native development tools, can I still use the Native Client SDK?
 176 --------------------------------------------------------------------------------------
 177
 178 You may find our :doc:`Tutorial <devguide/tutorial/index>` and :doc:`Building
 179 instructions <devguide/devcycle/building>` useful, and you can look at
 180 the code and Makefiles for the SDK examples to understand how the
 181 examples are built and run.
 182
 183 You'll need to learn how to use some tools (like GCC, LLVM, make, Eclipse,
 184 Visual Studio, or Xcode) before you can get very far with the SDK. Try seaching
 185 for an `introduction to GCC`_.
 186
 187
 188 Openness, and Supported Architectures and Languages
 189 ===================================================
 190
 191 Is Native Client open? Is it a standard?
 192 ----------------------------------------
 193
 194 Native Client is completely open: the executable format is open and the
 195 `source code is open <https://code.google.com/p/nativeclient/>`_. Right
 196 now the Native Client project is in its early stages, so it's premature
 197 to consider Native Client for standardization.
 198
 199 We consistenly try to document our design and implementation and hope to
 200 standardize Portable Native Client when it gains more traction. A good
 201 example is our :doc:`PNaCl bitcode reference manual
 202 <reference/pnacl-bitcode-abi>`.
 203
 204 What are the supported instruction set architectures?
 205 -----------------------------------------------------
 206
 207 Portable Native Client uses an architecture-independent format (the
 208 ``.pexe``) which can currently be translated to execute on processors
 209 with the x86-32, x86-64, and ARM instruction set architectures, as well
 210 as experimental support for MIPS. As new architectures come along and
 211 become popular we expect Portable Native Client to support them without
 212 developers having to recompile their code.
 213
 214 Native Client can currently execute on the same architectures as
 215 Portable Native Client but is only supported on the Chrome Web
 216 Store. Native Client's ``.nexe`` files are architecture-dependent and
 217 cannot adapt to new architectures without recompilation, we therefore
 218 deem them better suited to a web store than to the open web.
 219
 220 With Portable Native Client we deliver a system that has comparable
 221 portability to JavaScript and can adapt to new instruction set
 222 architectures without requiring recompilation. The web is better when
 223 it's platform-independent, and we'd like it to stay that way.
 224
 225 .. _other_languages:
 226
 227 Do I have to use C or C++? I'd really like to use another language.
 228 -------------------------------------------------------------------
 229
 230 Right now only C and C++ are supported directly by the toolchain in the SDK. C#
 231 and other languages in the .NET family are supported via the `Mono port`_ for
 232 Native Client. Moreover, there are several ongoing projects to support
 233 additional language runtimes (e.g. `naclports supports Lua, Python and Ruby`_)
 234 as well as to compile more languages to LLVM's intermediate representation
 235 (e.g. support Halide_, Haskell with GHC_ or support Fortran with flang_), or
 236 transpile languages to C/C++ (source-to-source compilation).
 237
 238 If you're interested in getting other languages working, please contact the
 239 Native Client team by way of the native-client-discuss_ mailing list.
 240
 241 Do you only support Chrome? What about other browsers?
 242 ------------------------------------------------------
 243
 244 We aim to support multiple browsers. However, a number of features that
 245 we consider requirements for a production-quality system that keeps the
 246 user safe are difficult to implement without help from the
 247 browser. Specific examples are an out-of-process plugin architecture and
 248 appropriate interfaces for integrated 3D graphics. We have worked
 249 closely with Chromium developers to deliver these features and we are
 250 eager to collaborate with developers from other browsers.
 251
 252 What's the difference between NPAPI and Pepper?
 253 -----------------------------------------------
 254
 255 :doc:`Pepper <pepper_stable/index>` (also known as PPAPI) is a new API that
 256 lets Native Client modules communicate with the browser. Pepper supports
 257 various features that don't have robust support in NPAPI, such as event
 258 handling, out-of-process plugins, and asynchronous interfaces. Native
 259 Client has transitioned from using NPAPI to using Pepper.
 260
 261 Is NPAPI part of the Native Client SDK?
 262 ---------------------------------------
 263
 264 NPAPI is not supported by the Native Client SDK, and is `deprecated in Chrome`_.
 265
 266 Does Native Client support SIMD vector instructions?
 267 ----------------------------------------------------
 268
 269 Native Client currently supports SSE on x86 and NEON on ARM. Support for
 270 AVX on x86 is under way.
 271
 272 Portable Native Client supports portable SIMD vectors, as detailed in
 273 :ref:`Portable SIMD Vectors <portable_simd_vectors>`.
 274
 275 Can I use Native Client for 3D graphics?
 276 ----------------------------------------
 277
 278 Yes. Native Client supports `OpenGL ES 2.0`_.
 279
 280 To alert the user regarding their hardware platform's 3D feature set
 281 before loading a large NaCl application, see :doc:`Vetting the driver in
 282 Javascript <devguide/coding/3D-graphics>`.
 283
 284 Some GL extensions are exposed to Native Client applications, see the `GLES2
 285 file`_.  This file is part of the GL wrapper supplied by the library
 286 ``ppapi_gles2`` which you'll want to include in your project.  In most cases
 287 extensions map to extensions available on other platforms, or differ very
 288 slightly (if they differ, the extension is usually CHROMIUM or ANGLE instead of
 289 EXT).
 290
 291 .. TODO Improve documentation for GL extensions.
 292
 293 Does Native Client support concurrency/parallelism?
 294 ---------------------------------------------------
 295
 296 Native Client and Portable Native Client both support pthreads,
 297 C11/C++11 threads, and low-level synchronization primitives (mutex,
 298 barriers, atomic read/modify/write, compare-and-exchange, etc...), thus
 299 allowing your Native Client application to utilize several CPU cores.
 300 Note that this allows you to modify datastructures concurrently without
 301 needing to copy them, which is often a limitation of shared-nothing
 302 systems. For more information see :ref:`memory model and atomics
 303 <memory_model_and_atomics>` and :ref:`threading
 304 <language_support_threading>`.
 305
 306 Native Client doesn't support HTML5 Web Workers directly but can
 307 interact with JavaScript code which does.
 308
 309
 310 Coming Soon
 311 ===========
 312
 313 Do Native Client modules have access to external devices?
 314 ---------------------------------------------------------
 315
 316 At this time Native Client modules do not have access to serial ports,
 317 camera devices, or microphones: Native Client can only use native
 318 resources that today's browsers can access. However, we intend to
 319 recommend such features to the standards bodies and piggyback on their
 320 efforts to make these resources available inside the browser.
 321
 322 You can generally think of Pepper as the C/C++ bindings to the
 323 capabilities of HTML5. The goal is for Pepper and JavaScript to evolve
 324 together and stay on par with each other with respect to features and
 325 capabilities.
 326
 327
 328 Security and Privacy
 329 ====================
 330
 331 What happens to my data when I use Native Client?
 332 -------------------------------------------------
 333
 334 Users can opt-in to sending usage statistics and crash information in
 335 Chrome, which includes usage statistics and crash information about
 336 Native Client. Crashes in your code won't otherwise send your
 337 information to Google: Google counts the number of such crashes, but
 338 does so anonymously without sending your application's data or its debug
 339 information.
 340
 341 For additional information about privacy and Chrome, see the `Google Chrome
 342 privacy policy`_ and the `Google Chrome Terms of Service`_.
 343
 344 How does Native Client prevent sandboxed code from doing Bad Things?
 345 --------------------------------------------------------------------
 346
 347 Native Client's sandbox works by validating the untrusted code (the
 348 compiled Native Client module) before running it. The validator checks
 349 the following:
 350
 351 * **Data integrity:** No loads or stores are permitted outside of the
 352   data sandbox. In particular this means that once loaded into memory,
 353   the binary is not writable. This is enforced by operating system
 354   protection mechanisms. While new instructions can be inserted at
 355   runtime to support things like JIT compilers, such instructions will
 356   be subject to runtime verification according to the following
 357   constraints before they are executed.
 358 * **No unsafe instructions:** The validator ensures that the Native
 359   Client application does not contain any unsafe instructions. Examples
 360   of unsafe instructions are ``syscall``, ``int``, and ``lds``.
 361 * **Control flow integrity:** The validator ensures that all direct and
 362   indirect branches target a safe instruction.
 363
 364 The beauty of the Native Client sandbox is in reducing "safe" code to a
 365 few simple rules that can be verified by a small trusted validator: the
 366 compiler isn't trusted. The same applies to Portable Native Client where
 367 even the ``.pexe`` to ``.nexe`` translator, a simplified compiler
 368 backend, isn't trusted: it is validated before executing, and so is its
 369 output.
 370
 371 In addition to static analysis of untrusted code, the Native Client runtime also
 372 includes an outer sandbox that mediates system calls. For more details about
 373 both sandboxes, see `Native Client: A Sandbox for Portable, Untrusted x86 Code`_
 374 (PDF).
 375
 376 How does Google know that the safety measures in Native Client are sufficient?
 377 ------------------------------------------------------------------------------
 378
 379 Google has taken several steps to ensure that Native Client's security works,
 380 including:
 381
 382 * Open source, peer-reviewed papers describing the design.
 383 * A :doc:`security contest <community/security-contest/index>`.
 384 * Multiple internal and external security reviews.
 385 * The ongoing vigilance of our engineering and developer community.
 386
 387 Google is committed to making Native Client safer than JavaScript and other
 388 popular browser technologies. If you have suggestions for security improvements,
 389 let the team know, by way of the native-client-discuss_ mailing list.
 390
 391 Development
 392 ===========
 393
 394 How do I debug?
 395 ---------------
 396
 397 Instructions on :ref:`debugging the SDK examples
 398 <debugging_the_sdk_examples>` using GDB are available. You can also
 399 debug Native Client modules with some :doc:`alternative approaches
 400 <devguide/devcycle/debugging>`.
 401
 402 How do I build x86-32, x86-64 or ARM ``.nexes``?
 403 ------------------------------------------------
 404
 405 By default, the applications in the ``/examples`` folder create
 406 architecture-independent ``.pexe`` for Portable Native Client. To
 407 generate a ``.nexe`` targetting one specific architecture using the
 408 Native Client or Portable Native Client toolchains, see the
 409 :doc:`Building instructions <devguide/devcycle/building>`.
 410
 411 How can my web application determine which ``.nexe`` to load?
 412 -------------------------------------------------------------
 413
 414 Your application does not need to make the decision of loading an
 415 x86-32, x86-64 or ARM ``.nexe`` explicitly---the Native Client runtime
 416 examines a manifest file (``.nmf``) to pick the right ``.nexe`` file for
 417 a given user. You can generate a manifest file using a Python script
 418 that's included in the SDK (see the ``Makefile`` in any of the SDK
 419 examples for an illustration of how to do so). Your HTML file specifies
 420 the manifest filename in the ``src`` attribute of the ``<embed>``
 421 tag. You can see the way the pieces fit together by examining the
 422 examples included in the SDK.
 423
 424 Is it possible to build a Native Client module with just plain C (not C++)?
 425 ---------------------------------------------------------------------------
 426
 427 Yes. See the ``"Hello, World!"`` in C example in the SDK under
 428 ``examples/tutorial/using_ppapi_simple/``, or the Game of Life example
 429 under ``examples/demo/life/life.c``.
 430
 431 What UNIX system calls can I make through Native Client?
 432 --------------------------------------------------------
 433
 434 Native Client doesn't directly expose any system calls from the host OS
 435 because of the inherent security risks and because the resulting
 436 application would not be portable across operating systems. Instead,
 437 Native Client provides portable cross-OS abstractions wrapping or
 438 proxying OS functionality or emulating UNIX system calls. For example,
 439 Native Client provides an ``mmap()`` system call that behaves much like
 440 the standard UNIX ``mmap()`` system call.
 441
 442 Is my favorite third-party library available for Native Client?
 443 ---------------------------------------------------------------
 444
 445 Google has ported several third-party libraries to Native Client; such libraries
 446 are available in the naclports_ project. We encourage you to contribute
 447 libraries to naclports, and/or to host your own ported libraries, and to let the
 448 team know about it on native-client-discuss_ when you do.
 449
 450 Do all the files in an application need to be served from the same domain?
 451 --------------------------------------------------------------------------
 452
 453 The ``.nmf``, and ``.nexe`` or ``.pexe`` files must either be served from the
 454 same origin as the embedding page or an origin that has been configured
 455 correctly using CORS_.
 456
 457 For applications installed from the Chrome Web Store the Web Store manifest
 458 must include the correct, verified domain of the embedding page.
 459
 460 Portability
 461 ===========
 462
 463 Do I have to do anything special to make my application run on different operating systems?
 464 -------------------------------------------------------------------------------------------
 465
 466 No. Native Client and Portable Native Client applications run without
 467 modification on all supported operating systems.
 468
 469 However, to run on different instruction set architectures (such as
 470 x86-32, x86-64 or ARM), you currently have to either:
 471
 472 * Use Portable Native Client.
 473 * Build and supply a separate ``.nexe`` file for each architecture, and
 474   make them available on the Chrome Web Store. See :doc:`target
 475   architectures <devguide/devcycle/building>` for details about which
 476   ``.nexe`` files will run on which architectures.
 477
 478 How easy is it to port my existing native code to Native Client?
 479 ----------------------------------------------------------------
 480
 481 In most cases you won't have to rewrite much, if any, code. The Native
 482 Client-specific tools, such as ``pnacl-clang++`` or ``x86_64-nacl-g++``,
 483 take care of most of the necessary changes. You may need to make some
 484 changes to your operating system calls and interactions with external
 485 devices to work with the web. Porting existing Linux libraries is
 486 generally straightforward, with large libraries often requiring no
 487 source change.
 488
 489 The following kinds of code may be more challenging to port:
 490
 491 * Code that does direct TCP/IP or UDP networking. For security reasons
 492   these APIs are only available to packaged applications, not on the
 493   open web, after asking for the appropriate permissions. Native Client
 494   is otherwise restricted to the networking APIs available in the
 495   browser.
 496 * Code that creates processes, including UNIX forks. Creating processes
 497   is not supported for security reasons. However, threads are supported.
 498 * Code that needs to do local file I/O. Native Client is restricted to
 499   accessing URLs and to local storage in the browser (the Pepper file I/O API
 500   has access to the same per-application storage that JavaScript has via Local
 501   Storage). HTML5 File System can be used, among others. For POSIX compatabiliy
 502   the Native Client SDK includes a library called nacl_io which allows the
 503   application to interact with all these types of files via standard POSIX I/O
 504   functions (e.g. open/fopen/read/write/...). See :doc:`Using NaCl I/O
 505   <devguide/coding/nacl_io>` for more details.
 506
 507 .. _faq_troubleshooting:
 508
 509 Troubleshooting
 510 ===============
 511
 512 My ``.pexe`` isn't loading, help!
 513 ---------------------------------
 514
 515 * You must use Google Chrome version 31 or greater for Portable Native
 516   Client. Please `upgrade now <http://www.google.com/chrome/>`_ if you are
 517   not. If you're already using a recent version,  open ``about:components`` and
 518   "Check for update" for PNaCl. Find your version of chrome by openning
 519   ``about:chrome``.
 520 * A PNaCl ``.pexe`` must be compiled with pepper_31 SDK or higher. :ref:`Update
 521   your bundles <updating-bundles>` and make sure you're using a version of
 522   Chrome that matches the SDK version.
 523 * Your application can verify that Portable Native Client is supported
 524   in JavaScript with ``navigator.mimeTypes['application/x-pnacl'] !==
 525   undefined``. This is preferred over checking the Chrome version.
 526
 527 My ``.nexe`` files never finish loading. What gives?
 528 ----------------------------------------------------
 529
 530 Here are ways to resolve some common problems that can prevent loading:
 531
 532 * You must use Google Chrome version 14 or greater for Native Client.
 533 * If you haven't already done so, enable the Native Client flag in
 534   Google Chrome. Type ``about:flags`` in the Chrome address bar, scroll
 535   down to "Native Client", click the "Enable" link, scroll down to the
 536   bottom of the page, and click the "Relaunch Now" button (all browser
 537   windows will restart).
 538 * Verify that the Native Client plugin is enabled in Google Chrome. Type
 539   ``about:plugins`` in the Chrome address bar, scroll down to "Native
 540   Client", and click the "Enable" link. (You do not need to relaunch
 541   Chrome after you enable the Native Client plugin).
 542 * Make sure that the ``.nexe`` files are being served from a web
 543   server. Native Client uses the same-origin security policy, which
 544   means that modules will not load in pages opened with the ``file://``
 545   protocol. In particular, you can't run the examples in the SDK by
 546   simply dragging the HTML files from the desktop into the browser. See
 547   :doc:`Running Native Client Applications <devguide/devcycle/running>`
 548   for instructions on how to run the httpd.py mini-server included in
 549   the SDK.
 550 * The ``.nexe`` files must have been compiled using SDK version 0.5 or
 551   greater.
 552 * You must load the correct ``.nexe`` file for your machine's specific
 553   instruction set architecture (x86-32, x86-64 or ARM). You can ensure
 554   you're loading the correct ``.nexe`` file by building a separate
 555   ``.nexe`` for each architecture, and using a ``.nmf`` manifest file to
 556   let the browser select the correct ``.nexe`` file. Note: the need to
 557   select a processor-specific ``.nexe`` goes away with Portable Native
 558   Client.
 559 * If things still aren't working, :doc:`ask for help <help>`!
 560
 561
 562 .. _`PNaCl SIMD: Speed on the Web`: https://www.youtube.com/watch?v=675znN6tntw&list=PLOU2XLYxmsIIwGK7v7jg3gQvIAWJzdat_
 563 .. _Adapting Software Fault Isolation to Contemporary CPU Architectures: https://nativeclient.googlecode.com/svn/data/site/NaCl_SFI.pdf
 564 .. _`Native Client: A Sandbox for Portable, Untrusted x86 Code`: http://research.google.com/pubs/pub34913.html
 565 .. _Crouton: https://github.com/dnschneid/crouton
 566 .. _experimental development environment which runs within NaCl: https://www.youtube.com/watch?v=OzNuzBDEWzk&list=PLOU2XLYxmsIIwGK7v7jg3gQvIAWJzdat_
 567 .. _introduction to GCC: https://www.google.com/search?q=gcc+introduction
 568 .. _Mono port: https://github.com/elijahtaylor/mono
 569 .. _naclports supports Lua, Python and Ruby: https://code.google.com/p/naclports/source/browse#svn%2Ftrunk%2Fsrc%2Fexamples%2Ftools
 570 .. _Halide: http://halide-lang.org/
 571 .. _GHC: http://www.haskell.org/ghc/docs/latest/html/users_guide/code-generators.html
 572 .. _flang: https://flang-gsoc.blogspot.ie/2013/09/end-of-gsoc-report.html
 573 .. _native-client-discuss: https://groups.google.com/group/native-client-discuss
 574 .. _deprecated in Chrome: http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
 575 .. _OpenGL ES 2.0: https://www.khronos.org/opengles/
 576 .. _GLES2 file: https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/lib/gl/gles2/gles2.c
 577 .. _Google Chrome privacy policy: https://www.google.com/chrome/intl/en/privacy.html
 578 .. _Google Chrome Terms of Service: https://www.google.com/chrome/intl/en/eula_text.html
 579 .. _naclports: https://code.google.com/p/naclports
 580 .. _CORS: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing