Re: direct_state_access_memory?

Do something about the big/little endian issue that can happen when transporting information from one to another machine.

You cannot transport the stored shader binaries from one computer to another, that's not what ARB_get_program_binary is for.
If you check the extension spec you can clearly see that it is primarily only for caching as there is no guarantee that the binary format will be the same across operating systems, hardware vendors or even driver versions.

Little endian seems to have a technical advantage here.
(Simpler circuit for doing the same.)

The best choice seems that every file would be best written in/with little endian.

(I find the bigger memory location is more significant byte very intuitive and logical.)

Why? What does "simper circuit" do with how you store a binary data on disk? Also the shader binary is just an array of bytes. Why endianness matter there?

Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/