Why Does Microsoft Still Offer a 32-bit OS?
This is a terrible article.<p>&gt; The main gigantic upside of a 64-bit process is the ability to support more than 2 GBytes of RAM ... Since only 1.6% of Backblaze customers have 2 GBytes or less of RAM, the other 98.4% desperately need 64-bit support, period, end of story.<p>This would only be true if all those Backblaze customers were only running one process on their machines. With PAE, A 32-bit system can support more than 2 GB, just not a 32-bit process. And actually, there are workarounds available to enable even that.<p>&gt; And remember, there is no downside.<p>There is a downside. 64-bit systems consume more RAM since every pointer and word is double the size. This could mean a performance penalty due to more swapping too.<p>&gt; Because there is zero downside, the first time it could, Apple shipped with 64-bit OS support.<p>No, Apple did this because they are in control of the hardware their OS runs on, so they can ensure that everyone is supported. Microsoft don&#x27;t have that luxury. Even then, Apple was still building for 32-bit just 5 years ago. They also weren&#x27;t first to support it as the author seems to imply -- 64-bit Windows XP was available before OSX even ran on Intel CPUs.<p>&gt; There are a variety of security features such as ASLR (Address Space Layout Randomization) that work best in 64-bits. The 32-bit version is inherently less secure.<p>Yeah, in the sense that it&#x27;s easier to guess a 32-bit long number than a 64-bit long number. It&#x27;s still unfathomable.<p>&gt; Supporting both versions is complicated. The more data our customers have, the more momentarily RAM intensive some functions (like inheriting backup state) can be. The more data you have the bigger the problem. Backblaze customers who accidentally chose to disable 64-bit operations are then going to have problems.<p>Has Backblaze honestly ever had this problem, where 2GB of RAM was not enough to reliably find a customer&#x27;s backup state? That seems ridiculous to me.