The user comes first
You might be a large corporation or a freelance developer, but it you’re in the software business you’re working for the end-user even if you don’t even know a single one of them. And let me tell you something about them: they’re stupid, but they hate to realize.
You want to make profit of your work, you have to make your user feel clever… or at least, don’t make him feel stupid or frustrated. A lot of users change powerful software for a crappy one that’s easy. I’m not saying technical quality is not important, I’m saying that if it two different applications can do the job, users will use the one which makes them feel clever by doing the job with less irritating error messages or cryptic questions.
Why so many users recommend using 32 bits?
Because they’re scared. They don’t know what 64 bits is apart from being the double of 32 bits… what they know is that some of their friends were using 64 bits and had to fallback to 32 because their applications weren’t working or the computer was unstable or… who knows what, but something wasn’t working.
But, is that true or is just a legend?
I’m afraid both. If we’re talking about windows, 32 bits applications will work on a 64 bits Windows without issues… but (there’s always a but) 16 bits applications will not work neither 32 bits drivers.
This means that if you’re running very old applications (MS-DOS and Windows 3.11 mainly) and you switch to 64 bits, you’re going to run into troubles. This is indeed a problem for business, but normal end-users do not rely on ancient software. However, they rely on something equally bad: cheap and crappy hardware.
Windows provides drivers for most common hardware, but it is likely that some bits of your system won’t be covered by the catalog windows offers. There is where hardware vendors step in providing you drivers for your operating system. A lot of 64-bits windows users found out, sadly, that their hardware vendors won’t provide 64 bits drivers (welcome to the Linux world, where your hardware vendor will tell you “I don’t care”).
32, 64 bits… who cares?
Let’s be honest. Users don’t care if your application is using 64, 32 bits or a giant wheel powered by a hamster. They want to do their job as fast as possible, knowing the minimum about the tool (ideally nothing) so they can move to important things (like watching big brother, or reading The Sun, but that’s another story).
However, as engineers we know that 64 bits is the right choice because we’re using more and more memory every day (chrome is actually eating memory) and relying on “tricks” like PAE is not a solution but a workaround.
The question is not if we should move to 64 bits, but how.
Universal Binaries: The Holy Grail
The solution to having to know about the architecture and choosing the right binary is: Universal binaries. Apple also used this solution when they changed their PowerPCs for Intel microprocessors.
The basic idea is to create a binary that would work on both, 32 and 64 bits by including both versions of the binary merged. Besides this, due to the particular way applications are packaged in MacOS X, applications have only one download for all architectures and all languages.
This is great for the user. It doesn’t matter if he’s using one or another architecture, in English or in Russian…. the same file is going to work smoothly and in the correct language.
The downside
Universal Binaries are the holy grail because the user doesn’t need to know anything. However, they achieve this by including binaries for all supported architectures and languages within the same distribution. Which means that the size of the application is going to be multiplied by the number of architectures supported and increased by the amount of languages included.
I’ve a 64 bits Intel Processor and I use everything in English. Why should I download application three times larger than expected (some of them have 64 and 32 bits versions along with a PowerPC version) and with support for German if I don’t have those processors and I can’t read German?
As an example, Google’s uploader for Google Music, called Music Manager, weights 45MB. After removing languages other than English and unused architectures (in this case, PowerPC support) the size is 11.7MB. In other words, I’ve an application that sizes nearly 4 times what it should.
Fortunately enough, there is software, like Xslimmer to strip out the unnecessary architecture and language support from our applications. But take this with caution, because this procedure could cause some updating methods to fail. Moreover, some applications won’t survive the process because realizing their size has changed, they refuse to work assuming they’re corrupted or tampered. You’re warned.
