Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

Thread: Google Wants LLVM To Mainline x32 ABI Support

  1. #11
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote Originally Posted by newwen View Post
    I really thought nobody was using Native Client. It will boost very much their Chrome OS.
    Anyway, being sandboxed, despite its benefits regarding security, I find it pretty limiting for real world apps, except games. If it can't even access the filesystem it is pointless to port any non-game app to Native Client for Chrome
    I don't understand why people would develop for Native Client instead of just using Flash. Wouldn't you want to allow anyone to run the program, rather than restricting it to just Chrome?

  2. #12
    Join Date
    Aug 2010
    Posts
    58

    Thumbs down

    Quote Originally Posted by smitty3268 View Post
    I don't understand why people would develop for Native Client instead of just using Flash. Wouldn't you want to allow anyone to run the program, rather than restricting it to just Chrome?
    I think you don't know Native Client enough to say this.
    Native Client is an OPEN SOURCE technology which allows you to run NATIVE CODE inside your BROWSER (which no one said it is only Chrome) inside a sandbox which ensures you SECURITY by only allowing a restricted set of instructions to be run.
    All the instructions executed by Native Client must be aligned and all resources used by them must pass through Pepper which exposes only the same resource that a Javascript application would have access.
    This is very very different from Flash.
    Flash is closed source, you must pay a huge amount of money to access the development tools and all your code must be written in ActionScript.

    Since Phoronix is, in my opinion, concerned about Open Source technologies, I think that Native Client is great enough to not be talked about.
    There are plenty of games, which some are from major studios and publishers that are developed to be run in Native Client and could take advantage from many of the technologies that the Open Source community develops.
    In Native Client you can take advantage from OpenGL ES 2.0 API and create console quality games.
    I would suggest people who don't know what NaCl is capable of, to try these games:
    From Dust
    Lara Croft and the Guardian of Light

    These games, with great quality, were available to Linux users, months before Steam came to Linux.
    There is nothing like that made in Flash.

  3. #13
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote Originally Posted by fernandoc1 View Post
    I think you don't know Native Client enough to say this.
    Native Client is an OPEN SOURCE technology which allows you to run NATIVE CODE inside your BROWSER (which no one said it is only Chrome) inside a sandbox which ensures you SECURITY by only allowing a restricted set of instructions to be run.
    All the instructions executed by Native Client must be aligned and all resources used by them must pass through Pepper which exposes only the same resource that a Javascript application would have access.
    That's pretty much exactly like Flash, except that Chrome is open source while the main Flash implementation is not. (Although there are flash alternatives that are).
    This is very very different from Flash.
    No, it's really not.

  4. #14
    Join Date
    Aug 2010
    Posts
    58

    Cool

    Quote Originally Posted by smitty3268 View Post
    That's pretty much exactly like Flash, except that Chrome is open source while the main Flash implementation is not. (Although there are flash alternatives that are).

    No, it's really not.
    Ok, you are right.
    Let's take advantage of the latest and greatest closed source features from Adobe's Flash Player which was always great and had the best support for every operating system (outstanding stability on Linux) and with the best 3D API's to make the best games the Web has ever seen.

  5. #15
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote Originally Posted by fernandoc1 View Post
    Ok, you are right.
    Let's take advantage of the latest and greatest closed source features from Adobe's Flash Player which was always great and had the best support for every operating system (outstanding stability on Linux) and with the best 3D API's to make the best games the Web has ever seen.
    I'd probably just use Steam instead.

  6. #16
    Join Date
    Sep 2012
    Posts
    332

    Default

    32-bit pointers are insecure because of inefficient Address space layout randomization (ASLR).

  7. #17
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

    Quote Originally Posted by JS987 View Post
    32-bit pointers are insecure because of inefficient Address space layout randomization (ASLR).
    1. ASLR is just makes attacks harder.
    2. Attacker can reduce searching to virtual memory size. (so ASLR is more efficient with 64-bit pointers, only if you have more than 2^32 virtual memory)
    Last edited by LightBit; 01-24-2013 at 08:11 AM.

  8. #18
    Join Date
    Sep 2012
    Posts
    332

    Default

    Quote Originally Posted by LightBit View Post
    1. ASLR is just makes attacks harder.
    2. Attacker can reduce searching to virtual memory size. (so ASLR is more efficient with 64-bit pointers, only if you have more than 2^32 virtual memory)
    I have 2^45 virtual memory according to /proc/meminfo
    According to http://www.stanford.edu/~blp/papers/asrandom.pdf 64-bit is more secure because of more bits of randomization.

  9. #19
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    389

    Default

    Quote Originally Posted by JS987 View Post
    I have 2^45 virtual memory according to /proc/meminfo
    If I understand correctly x32 is more for low memory devices.


    Quote Originally Posted by JS987 View Post
    According to http://www.stanford.edu/~blp/papers/asrandom.pdf 64-bit is more secure because of more bits of randomization.
    Shall we use 128-bit pointers just to prevent brute force attack?
    40-bit (64-bit) can be brute forced quite fast.

  10. #20
    Join Date
    Sep 2012
    Posts
    332

    Default

    Quote Originally Posted by LightBit View Post
    Shall we use 128-bit pointers just to prevent brute force attack?
    40-bit (64-bit) can be brute forced quite fast.
    Brute force attack isn't always possible and can be detected.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •