Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Server software has been 64-bit only for a while now (Since Server 2008 R2 for Windows, even earlier for Exchange and Sharepoint) and even Ubuntu are pushing you away from 32-bit versions for their server OSes.

But is there any good, quantifiable reason to keep a 32-bit desktop operating system maintained? We're preparing our Windows 8 images for the (unfortunate?) few that will be early adopters.

The majority of our desktop computers have 4gb or less of RAM, but I would love to not have to bother supporting a 32-bit flavoured operating system any more.

Any reason why I should?

share|improve this question
17  
The all answers comes down to "to run software that runs only under this system" –  lukas Sep 18 '12 at 3:27
    
@lukas - it would appear to be. To which the answer to my specific scenario is "No, no good reason" as all our software is 64-bit compatible. Which is what I was hoping for, there's no major catch that will explode in my face in a few months (assuming we test thorougly) –  Mark Henderson Sep 18 '12 at 4:26
6  
Don't forget hardware without 64-bit drivers though? –  Svish Sep 18 '12 at 11:54
    
Some hardware needs it. Depends on your setup. First, and some second generation Atom netbooks only work on 32bit OS's. –  Xeoncross Sep 18 '12 at 14:51
1  
@Xeoncross It's not just older Atom systems. Intel's current D2500/2700 desktop Atoms have a powerVR GPU and only have win32 drivers. –  Dan Neely Sep 18 '12 at 17:21

12 Answers 12

up vote 53 down vote accepted
  • 32-bit can be slightly faster in certain use cases -- the smaller addresses means sightly more compact code, which means greater cache efficiency. In the benchmarks I've seen, that efficiency tends to be be overshadowed by 64-bit's greater computational efficiency in heavy-computation environments. But 32-bit does in fact occasionally win on some benchmarks. YMMV. The age of your software matters, as newer builds take advantage of 64-bit stuff that older builds do not.

  • More compact code means less disk space. Just go download the ISOs for your favorite OS in 64 and 32 -bit flavors to see the difference. It's not trivial. It's also quite a lot more once you uncompress the binaries. As pointed out by OrangeDog: Much of this space consumption comes from the fact that 64-bit OSes ship 32-bit libraries in addition to the 64-bit ones.

  • You still get better compatibility with legacy components and software with 32-bit. This is particularly visible in systems that dynamically compile on the host machine but pull in 3rd-party binary libraries at the same time. Microsoft's .NET framework is a great example of this: while the programs are theoretically architecture-independent, anytime you link to a native binary you tie to one arch or the other. Many developers don't even know this is happening, and ship production components that will fail to run on 64-bit systems without some tweaking to explicitly instruct .NET to run in 32-bit mode. Most people don't know how to do this.

  • As pointed out by Daniel B: Windows .NET development on 64-bit machines leaves you open to a frustrating inconsistency where under certain circumstances exceptions are masked by the OS.

  • Legacy hardware. You can't run a 32-bit driver on a 64-bit kernel.

None of this adds up to a show-stopper for most people. Still, you have to decide how these factors affect your environment.

share|improve this answer
1  
The most complete answer so far. +1 –  DejanLekic Sep 18 '12 at 8:20
2  
Just FYI on performance. 64-bit code can be faster due to more registers, esp if doing a lot of integer work. –  Macke Sep 18 '12 at 8:35
14  
64-bit OS ISOs are bigger because they also contain the entirety of a 32-bit system in order to support both kinds of executable. The massive size difference is not because 64-bit binaries are bigger (they are, but not significantly). –  OrangeDog Sep 18 '12 at 8:59
3  
@OrangeDog: that's comparing apples and oranges. "Damn we have half the food, but at least the plate is big!" –  orlp Sep 18 '12 at 16:56
1  
@Earlz archlinux.mirrors.uk2.net/iso/2012.09.07/arch looks like only 3M larger to me –  OrangeDog Sep 19 '12 at 9:11

The only reason I can think of to keep a 32-bit desktop operating system is if you use old 16 bit (e.g. DOS) programs and you do not have the windows version which supports Windows Virtual PC.

(And even then I would install a 64 bit OS and use something like DOSbox).

Edit: There actually is another reason: Hardware which fails to cope with more than 4GB address space. E.g. FireWire trying to do DMA. Or any (old) hardware with no 64 bit drivers.

share|improve this answer
    
Actually this is a very valid reason for keeping 32-bit around. I'd forgotten about this. Thankfully I don't think we have any 16-bit software left ;) –  Mark Henderson Sep 18 '12 at 0:35
3  
But there's free software to do that, so it's not really a good reason, is it? –  naught101 Sep 18 '12 at 6:23
3  
Non just MS-DOS based applications, also potentially Win16-based applications . –  Alan B Sep 18 '12 at 8:26
    
@Naught101: Yes, there is free software for DOS. And for windows there is always Vmware player, Oracle virtual box, windows virtual PC, wine for windows (assuming it works without 16 bit stuff) etc etc. Alan: 1) Indeed, though I haven't seen any old win16 programs in ages. Maybe I am lucky though. :) 2) Yes, hence the example gratia DOS. –  Hennes Sep 18 '12 at 12:46

Anything that will run Windows 8 is already 64-bit capable, unless you happen to have some first-generation Intel Atom netbooks (and I doubt that very much). That's about the only thing I can think of.

AMD released its first 64-bit capable Opteron in 2003; and since then virtually every processor they have made has been 64-bit capable.

Intel was a year later, releasing its first 64-bit Xeon (Nocona) in 2004, and expanding to just about the entire product line by 2006. Aside from the aforementioned early Atom chips, every Intel processor today is 64-bit.

Wikipedia has a broken down processor list if you're interested in ancient history.

share|improve this answer
    
Actually I think we do have a HP Mini 1st generation Atom, but it's still on XP and is way back in the "only touch if I have to" pile, so it's a bit of a non-issue. –  Mark Henderson Sep 18 '12 at 0:29
2  
And 64-bit XP was such a nightmare that nobody ever ran it anyway. No problem there. –  Michael Hampton Sep 18 '12 at 0:31
1  
I ran XPx64. It wasn't that bad. It just wasn't XP. If they'd called it what it actually was (Server 2003, lite edition) it probably wouldn't have been such a nightmare. –  HopelessN00b Sep 18 '12 at 2:52
    
Do not forget the first-generation Intel Core CPUs that were NOT 64-bit capable: en.wikipedia.org/wiki/List_of_Intel_Core_microprocessors. I found out the hard way... –  Panagiotis PJ Papadomitsos Nov 29 '12 at 15:37

Compatibility with Ancient Software/Hardware.

If everything works under x64, I wouldn't bother with 32 bit.

share|improve this answer
    
I guess this is a more of a "What doesn't work under 64-bit" question... –  Mark Henderson Sep 18 '12 at 0:37
2  
Printer drivers especially. "Standard paths" for programs become complicated when you have a mix of "Program Files" and "Program Files (x86)" too. –  Andrew Sep 18 '12 at 1:52

Many people don't know that 64-bit programs and libraries occupy more memory than 32-bit equivalents.

For example, when using low-memory virtual machines, it is advisable to use 32-bit operating systems to maximize memory availability inside that VM.

share|improve this answer

Memory addresses in a 64 bit machine naturally take 64 bits. Those same addresses take 32 bits in a 32 bit machine. Under some pretty exceptional circumstances, that "increase" in needed number of bits can be the difference between good performance and poor performance on a memory limited machine.

Beyond that, since you are likely to be running 32 bit software on a machine that could be running 64 bit software anyway, and 32 bit support works reasonably well on 64 bit machines, the differences on the hardware side are not game changing. Occasionally you will find a legacy device that doesn't have a 64 bit hardware driver, but that is now very rare due to 64 bit operating systems being available for over a decade.

One point to consider is that many older 32 bit applications are older in many ways beyond their bit-ness. On the windows OS side, a 32 bit app might get confused if it is looking for files in "Program Files" that are now located in "Program Files (x86)". Certain registry items likewise might need manual attention. Again this is more a function of slightly mis-written applications that now need your help to "find" things that would have "just worked" if the machine happened to be 32 bit.

share|improve this answer

Speaking of Ubuntu, we have been running 64-bit 12.04 LTS under LTSP for a few weeks now.

The only hassle we've run into for the initial beta testers is that the LTSP terminals we use (Dell GX2xx) require a 32-bit kernel and thus we have to compile a 2nd LTSP kernel and maintain twice as many packages for the two architectures.

LTSP being QUITE an edge case, I think 64-bit is fairly ready to go unless your particular testing shows a defect.

share|improve this answer

Although I'd personally recommend moving to 64-bit as soon as possible and just bite the bullet sooner rather than later, it won't be without impact to your IT support team. If the support team's bandwidth is already stretched to a maximum (i.e., already understaffed), then I'd actually consider waiting.

So, this is one answer that concerns human resources, not just software in/compatibility.

The roll-out should be of course carefully planned (preferably gradual rather than all-at-once). There are going to be issues "discovered" that will take hours to resolve on a per-user basis. Once the more common issues are identified, "how-to's" can guide faster resolutions for both support calls as well as self-service.

Mostly, (for example), I'm thinking of all the 32 and 64 bit (in)compatibility issues between the OS, a specific software package and the associated plugins, such as having both 32-bit and 64-bit browsers installed (and/or multiple browsers) on a single 64-bit OS, shortcuts for 'run as admin' vs 'run as normal user', having options for both a 32 and 64-bit plugin for those browsers (or sometimes maybe restricted to only 32-bit plugins which only work in one version of the browser) -- all that break applications and workflows built on top of those plugins. (By "plugins" I mean anything from Java to flash to embedded pdf readers to web conferencing software -- either built in-house or widely available, both commercial and free.) You can attempt to test for all of these issues, but it's hard to predict if a user will inadvertently install plugin B before plugin A, which causes a different result than another user who installs plugin A before plugin B (basically it's always hard to predict what damage users will do when their actions change the state of the system.)

share|improve this answer

The only reason to keep 32 bit versions of... anything... around is to support "legacy" applications and systems. If you can run everything on 64 bit OSes, count yourself lucky and move on. You could be like some poor SAs who are in a corporate environment for a non tech firm, where the plan for migrating from the user base from XP to Windows 7 starts in the thrid quarter of 2014.

<cries>

Anyway, I don't know about Shift+Del, and I'd probably just leave them ignored in some corner of the environment, in case the unspeakable happens and you find yourself needing Windows XP for something. Definitely stop bothering to maintain, update, test or anthing else on them, but keep them around should they ever be needed. It happened the other day that a client wanted me to support some Windows 2000 PoS, which I could, because I didn't blow away all my Server 2000 images when Server 2003 came out (and I really wanted to, too).

As much as you pray and hope that time never comes, it's always nice to have that stuff around "just in case," and the costs of keeping it are so insignificantly small, I think it's foolish not to.

share|improve this answer

Having had considerable problems due to legacy software issues I can only say to make sure everything you run can be run on a 64 bit OS. If it does then you have no reason not to migrate, assuming licensing isn't a factor.

In my case I was able to reconfigure systems so that all 32bit only applications were able to run on the one machine, allowing all the other workstations to be 64 bit. Eventually I even migrated that 32 bit machine to a VM on Virtualbox, running on a Debian host, mainly because the capacity was there and I wanted to reduce the box count.

share|improve this answer

We set up an ESX box to run virtual machines in a VPI setup. We made the guest VM's 32bit Win7 so that we can run more guests on a given ESX box. A 32 bit desktop is really happy with 1-2 GB RAM, running Office and the works. If we went x64, we would need more RAM per guest, and would need a much heftier box.

The bottom line: x64 is needed when it is needed.... When it is not, you are just sending more $ to the RAM makers....

share|improve this answer

All of the above and several virtual machines cannot run x64-bit code if the CPU doesn't support virtualization (e.g. VT-x feature).

Several cheaper 64-bit CPUs which lack VT-x, etc are however attractive for 'homemade' clusters.

From wikipedia:

Intel did not add segmentation support to its x86-64 implementation (Intel 64), making 64-bit software-only virtualization impossible on Intel CPUs, but Intel VT-x support makes 64-bit hardware assisted virtualization possible on the Intel platform

share|improve this answer
1  
-1 Only if the virtualization technology requires VT-x... Not all do. Beside that point, your "Answer" is little more than a comment on what might not work. That's not very helpful nor really qualifies as an Answer. –  Chris S Sep 18 '12 at 14:58
    
Chris S, you should familiarize with the abbreviation 'e.g.', and be less quick to downvote, especially on such a very broadly formulated question. Concretely, with an Intel B960 chipset I would hold on to 32bit OS images. –  Lo Sauer Sep 20 '12 at 15:53
    
Ego loqui, scio exempli gratia. –  Chris S Sep 20 '12 at 15:58

protected by Chris S Sep 18 '12 at 14:56

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.