Check it out:
I now have a 3520 by 1200 desktop on two displays, 4GB of RAM and a Dual Core E6750 CPU. That means I can have Blender and a web browser open side by side or I can have my text editor jEdit, a thesaurus/dictionary and treeline plus a web browser open without any overlapping windows.
Life doesn't get much better than this :-)
If you plan to buy yourself 2GB of Kingston HyperX RAM (KHX8500D2K2/2GN to be precise) for a Gigabyte GA-P35C-DS3R (BIOS Rev. mainboard, beware: I couldn't get it to work. I tried:
With DDR2-800/PC-6400 settings and 1.8V, the RAM would pass MemTest+ V1.70 but some applications would crash reliably (comix, for example, when opening the third file).
I've now replaced the modules with 2*2GB from G.Skill and the board is rock solid.
If you ever ran into the "Weird Path Twist" (a.k.a Z-Twist or curve singularity twist) in Blender, I've opened a bug against it: [#8022] Some operations on control points can introduce weird twists in paths
If you don't know Blender, here is what I did in two days:
It's the entrance to a public bath on the TAURUS. Since the corridor outside is perpendicular to the bath's ground, it's a gravity lock; in the center of the circular walkway, you can see the floor make a 90° turn downwards to align visitors with the gravity field of the bath. If you want to gaze, you can stay on the circular walkway and have a great view of the bath without craning your neck.
Another one for the futile/harmful optimization awards: The New & Noteworthy page for Eclipse 3.4M4 says:
The new 'Convert to StringBuffer' quick assist (Ctrl+1) transforms string concatenations into more efficient, albeit less compact, code using an explicit StringBuffer:
Hello? Since when is using StringBuffer more efficient than using String concatenation? Answer: It was upto Java 1.3 (or maybe 1.2; I'm too lazy to look it up right now).
With Java 1.4, the compiler used StringBuffer as well, so this optimization doesn't buy anything but makes the code harder to read.
Worse, with Java 1.5, the compiler generates more optimal code by using StringBuilder instead of StringBuffer. The builder is not synchronized; since string concatenation doesn't suffer from threading issues, this is safe and faster!
And the morale: If you optimize something, make sure you don't rely on some myth about X being faster than Y.
PS: Of course, there is already a bug tracking this.
