Announcement

Collapse
No announcement yet.

Google Wants LLVM To Mainline x32 ABI Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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?

    Comment


    • #12
      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.

      Comment


      • #13
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            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.

            Comment


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

              Comment


              • #17
                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; 24 January 2013, 09:11 AM.

                Comment


                • #18
                  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.

                  Comment


                  • #19
                    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.


                    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.

                    Comment


                    • #20
                      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.

                      Comment

                      Working...
                      X