Hot answers tagged 32bit-64bit
Well, there once was a chip called 8086, with a cheaper version called 8088 that was used in a personal computer called IBM PC. An improved version of that chip was made and called 80186, though that wasn't a very popular version. However, an improved improved version was then made, and called 80286. Now, that was a very popular chip, in particular because ...
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 ...
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 ...
Oh my... If you have 60Gb of RAM, please save yourself the hassle and use a 64-bit os. Also, 60 SQL instances sounds like a very odd way of doing things and I can't in good conscience suggest it. The amount of money a server of that stature costs, surely a proper SQL license would be in the budget? Windows is also incredibly intelligent when it comes to ...
under what conditions that it starts to make sense to use 64-bit installations. Under all except being idiotic. Sorry - what good would be installing a 32 bit database on a 64 bit server? And - imagine - SERVER 2008R2 is ONLY available in 64 bit. There is - today - no scenario where it makes sense to install a 32 bit SQL Server version if one has a ...
Probably because the x86 line became synonymous with 32 bit processors for quite some time, while x64 was specifically a designation for 64 bit as applications and operating systems were transitioned over, and now there are software applications that require the 64 bit designation in order to run (like some VM software). In other words, it's more marketing ...
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 ...
I think the question you should be really asking is why not go x64? If your hardware is supported and your apps work, what's the reason to stick with 32 bit? There is little to no cost difference and its the way all future software is going to move, Exchange 2007 for example is 64bit only and I'm sure many new pieces of software will go that way. If you ...
x64 versions of Windows do not support 32-bit kernel mode drivers. Microsoft's statements re: Vista are here (be sure to look at the errata at the bottom-- the article has a major mistake that it corrects), and the same is true for Windows 7 and Windows Server 2008. There is no magic "switch" you can throw to allow 32-bit kernel mode drivers to work on an ...
The fix in RHEL6 or in derivatives of RHEL6 is to add the parameter multilib_policy=all in your /etc/yum.conf file and that should work out. It will enable fetching packages of all architectures and is not limited to the 64 bit versions only.
x86_64 cpus do have the no-execute bit in their page tables. I.e. this can prevent security exploits caused by buffer overruns. 32-bit x86 cpus do only support this feature in the PAE mode. you can only used signed Windows drivers. IMHO this is an advantage because you can't break your system with a broken, untested driver. Remember, most Windows problems ...
x64 CPUs can actually run 32-bit (x86) code in parallel to 64-bit code. The WOW64 layer of Windows translates the system calls of 32-bit programs to the 64-bit system routines.
From Wikipedia: The term x86 refers to a family of instruction set architectures based on the Intel 8086 CPU.
I am not aware of any issues with the 64 bit version. It's a 64 bit CPU, so I would definitely run 64 bit. I have been on hundreds of servers with 64 bit CentOS and never experienced any strange issues related to the fact, that it is a 64 bit OS. Also, you cannot allocate more than 4 GB of RAM with 32 bit. So to sum it up; go 64 bit.
The lack of 32-bit processor support simply means that Server 2008 R2 will not ship with a 32-bit edition, which means it requires a 64-bit processor to run. It still runs 32-bit applications through the WOW64 compatibility layer.
Short answer, yes. You can almost always run 32bit software on 64bit hardware, just not the other way around. You can sometimes run 64bit software on a 32 bit host, as long as the hardware is 64bit, depending on the hypervisor. I currently have a Server 2008 Hyper-V role machine running several different OSes. I have about 6 WinXP 32 bit machines running, ...
Your kernel is a i686 version, so 32 bits.
There's no good reason to use a 32-bit OS for new deployments on modern hardware. You want to be able to address and utilize the resources available to you. Even if you deem that 32-bit is sufficient, 64-bit will be more future-proof. Finally, there's no easy move from 32-bit to 64-bit without a system reinstallation. From an administrative perspective, ...
Compatibility with Ancient Software/Hardware. If everything works under x64, I wouldn't bother with 32 bit.
Pretty much these days, I'd always be going with a 64-bit Linux. Hardly worth the problems (memory and process limitations) and efforts on a 32 bit system.
The only time you should care about whether your OS is 32-bit or 64-bit is when you have an application that specifically needs one of the two. If you do not have such an application requirement, and/or you have more than 3.2 GB of memory, you may as well just use 64-bit.
Most likely a licensing problem. As an example, the Standard Edition of Server 2003 64bit can use only 32GB of RAM, not for technical but licensing reasons. What Edition do you run?
32-bit versions are slightly more memory efficient than 64-bit versions, but probably not enough to notice and will fall out of maintenance sooner than 64-bit kinds. For OS chose whatever you're most comfortable with.
What does a 32-bit system use more than 3-4GB RAM for? Running things that benefit from lots of RAM, like database servers. (This was needed in high load environments before 64bit systems became generally available.) Will 32-bit Windows be able to use >4GB RAM? The right edition, with the right applications: Yes. It'll need to be a Server edition ...
WinPE is 32bit (by standard). If you download WAIK you can make a 64bit boot image, I remember seeing something packaged with TFTPBoot that may have been 64 bit, google it. :-)
You will need to switch to 64-bit edition in order to support more than 4GB of RAM with the Standard Edition. The Enterprise edition does support PAE for up to 32GB of RAM, but it's not the way you should go. Keep in mind that the edition of MSSQL 2005 is also very important. You will need either Standard or Enterprise to be able to use all the memory on ...
No it isn't. You need to upgrade to IIS7 for that. In IIS6 you can set the enable32BitAppOnWin64 flag to true to enable the entire IIS instance to run 32 bit applications even if the server operating system is 64 bit. In IIS7 you can set this flag per application - which isn't possible in IIS6. This is one way of doing it in IIS7 (can be done through UI and ...
PostgreSQL benefits from having a 64-bit build in two main ways. First, data types that can fit into 64-bits (larger integers and timestamp types mainly) can be more efficiently passed around directly in registers rather than using pointers. Second, it's possible to allocate more memory for the database's dedicated buffer cache. The point of diminishing ...
There are two ODBC dialogs on your system. One for 32bit and one for 64bit. The one you can reach via system control is the 64bit one. The 32bit version is located at C:\WINDOWS\SYSTEM32\ODBCAD32.EXE (on a 32bit Windows) C:\WINDOWS\SYSWOW64\ODBCAD32.EXE (on a 64bit Windows)
There is a step-by-step guide in the Debian Wiki to upgrade from 32 to 64 bit. http://wiki.debian.org/Migrate32To64Bit This is really ugly plus you have the problem with your Ruby installation. Are you sure your Ruby libs are running with 64 bit? I would do definitley do a full backup/image/whatever of the machine, so you can rollback to a functional state ...
Only top voted, non community-wiki answers of a minimum length are eligible