The Great PC RAM Swindle
appleinsider.com
appleinsider.com
Apple offered upgrades to 4gb of memory without explaining the disadvantages and Mac OS X Tiger showed the amount of physical memory rather than the amount addressable - http://forums.macrumors.com/showthread.php?t=364707 - why is it a "swindle" when Dell do it but not when Apple do it?
My one experience was deeply frightening (what do you mean I can't listen to music without having to maintain a 32bit userland?)
Dragon NaturallySpeaking -- even the just-released v.10 -- only runs on 32-bit Windows.
http://www.google.com/search?q=naturallyspeaking+32+64+windo...
And why does Microsoft still sell 32-bit Windows?
"Currently, Mac OS X Leopard hosts both 32-bit and 64-bit apps on top of a 32-bit kernel (below). Using PAE, the 32-bit kernel can address 32GB of RAM in the Mac Pro and Xserve; Apple's consumer machines only support 4GB RAM, but unlike 32-bit operating systems they can use the entire 4GB (with appropriate hardware support). Leopard's 32-bit kernel enabled Apple to ship 64-bit development tools to give coders the ability to build applications that can work with huge data sets in a 64-bit virtual memory space (and port over existing 64-bit code), without also requiring an immediate upgrade to all of Mac OS X's drivers and other kernel-level extensions. That transition will happen with Snow Leopard." http://www.appleinsider.com/articles/08/08/26/road_to_mac_os...
I don't know if this is right, but it caught my attention when I read it.
Unless you're doing CAD, 3D or video editing, 64-bit on the desktop is just for bragging.
However, it is much easier to write server applications that assume all data can fit in virtual memory. All of my new server-side applications assume that the entire dataset of every process can fit in the virtual address space of the system. Effectively, my applications now require 64-bit machines to handle more than 2GB of data. This allows me to use mmap() and normal memory management (malloc, etc.) and rely on the operating system's VMM to swap for me. This is a vast simplification over trying to implement your own user-space VMM just to handle large files on small (32-bit) systems. I expect that the next generation of server software will all be design this way, and a lot of desktop software will probably adopt this kind of design too.