If we define what untrusted code to mean random binary/library from internet that your program downloads at runtime and then executes.
Rust/C++ have no support for limiting what harm that random binary code does. It can do anything and any Rust/C++ compile time protections are moot because the downloaded binary/library is not compiled or checked against the expectations. Java sandbox (mostly used by applets) is an attempt to allow downloading binary (compiled java classes) from external source and limiting what it can do.
Trusted code is your own source and downloaded external libraries (depending on language the external libraries might be in source or binary format) one compiles into binary. While building trusted code the type checking of the Rust/C++/Java compilers is applied. Here Rust has the most multithread/data sharing checks.
When handling untrusted input processed by your trusted code the question becomes can it cause untrusted code execution. Java (and other languages running in virtual machines or interpreters) provides the most protections. Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.
Then why is that most of the more exotic printer/usb/laptop peripheral stuff does not work in 64bit Windows even after 2 years after the ABI was released?
It's because there cannot be one ABI for everything. Every once in a while the ABI must be broken, windows has now at least 4 ABIs: x86_32(w95,NT),x86_64(NT) and PPC(Xbox360). And the Windows Vista will increase that number to 6. And most HW/laptop companies just do not have the resources to write drivers for 6 different _windows_ ABIs.
The end result is that the newer laptops (64bit) actually work better in Linux than in Windows 64. This will become especially obvious with the next windows version when most of the existing laptops just stop working and will never have full driver support.
With Linux almost everything that worked before keeps working in the future. It just takes a bit of time for HW vendors to see that they should be doing the HW and let someone else write the drivers.
As all G400 owners should know. The BIOS default clock speeds under linux are much lower than those in Windows.
The author will redo the tests with correctly clocked G400 when he gets back from a business trip. See this forwarded post at Utah-GLX mailing list
Also, as the G400 is quite much CPU bound in the tests, I would believe that compiling the GLX with better gcc parameters should also have had an effect to the scores.
Slashdot Mirror
If we define what untrusted code to mean random binary/library from internet that your program downloads at runtime and then executes.
Rust/C++ have no support for limiting what harm that random binary code does. It can do anything and any Rust/C++ compile time protections are moot because the downloaded binary/library is not compiled or checked against the expectations.
Java sandbox (mostly used by applets) is an attempt to allow downloading binary (compiled java classes) from external source and limiting what it can do.
Trusted code is your own source and downloaded external libraries (depending on language the external libraries might be in source or binary format) one compiles into binary.
While building trusted code the type checking of the Rust/C++/Java compilers is applied. Here Rust has the most multithread/data sharing checks.
When handling untrusted input processed by your trusted code the question becomes can it cause untrusted code execution. Java (and other languages running in virtual machines or interpreters) provides the most protections. Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.
"NOMO grew out of a practical need. The better half of a co-founder kept complaining that she could not find well-fitting jeans from any store."
http://www.nomojeans.com/nomo/how_nomo_works
Then why is that most of the more exotic printer/usb/laptop peripheral stuff does not work in 64bit Windows even after 2 years after the ABI was released?
It's because there cannot be one ABI for everything. Every once in a while the ABI must be broken, windows has now at least 4 ABIs: x86_32(w95,NT),x86_64(NT) and PPC(Xbox360). And the Windows Vista will increase that number to 6.
And most HW/laptop companies just do not have the resources to write drivers for 6 different _windows_ ABIs.
The end result is that the newer laptops (64bit) actually work better in Linux than in Windows 64. This will become especially obvious with the next windows version when most of the existing laptops just stop working and will never have full driver support.
With Linux almost everything that worked before keeps working in the future. It just takes a bit of time for HW vendors to see that they should be doing the HW and let someone else write the drivers.
More realistic comparision would be:
Right to software piracy isn't constitutionally protected like the right to kill people with guns.
The author will redo the tests with correctly clocked G400 when he gets back from a business trip. See this forwarded post at Utah-GLX mailing list
Also, as the G400 is quite much CPU bound in the tests, I would believe that compiling the GLX with better gcc parameters should also have had an effect to the scores.