Hacker News new | past | comments | ask | show | jobs | submit login

I find the description of which image to choose confusing. You need the a 64-bit image to handle processes over 4GB, right? Why is the x86 version recommended for "most machines with Intel/AMD/etc type processors and almost all computers that run Microsoft Windows." (That's from the server description, too.)



I think it's almost entirely due to flash. Most users won't notice the difference between 32 and 64 bit machines, and it's still much simpler to use flash in a 32 bit browser. 32 bit chrome has flash bundled, and 64 bit chrome does not, which will cause confusion as well. At work, I use a 64bit OS with the pre-release of flash "square", but at home it's just easier to use 32 bit on my laptop.


I run Ubuntu 64 bit on all of my systems and I've never had to do anything to get Flash to run, not with Firefox 3.6, Firefox 4 or Chrome Dev channel.

Flash hasn't been an issue for quite some releases in Ubuntu.


> Flash hasn't been an issue for quite some releases in Ubuntu

Your personal experience doesn't make it true for everyone.

The official flash release has to be run through nspluginwrapper on 64-bit systems, which can be a pain when it doesn't work. Suggesting that the average user stick with the 32-bit release removes any support issues related to 32 vs 64-bit plugins (java included too) and nspluginwrapper, with no noticeable drawback for most users.


That's simply not true any longer. It just isn't. It's not "my personal experience". If you install ubuntu-restricted-extras, all of this is done transparently without ANY work on the users' part.

I would know, because I've never installed Flash manually on this system.


Yes, this is done transparently, and most people won't have a problem. As with most things Ubuntu, as long as you go with the defaults, everything will work smoothly.

What I'm saying, is that flash, java (plugin), and nspluginwrapper can be broken. It happens; and when it happens, it's not obvious what went wrong or how to fix it. Going 32-bit simply removes this support issue altogether.


No. Memory > 4GB is not a reason to use 64bit.

If you want to address > 4GB of RAM on 32bit, install the PAE kernel. I think the meta package is called linux-generic-pae.

Use 64bit if you want to run applications that will benefit from it.

EDIT: If in doubt, use the 32 bit one as it will give you less friction for general purpose desktop use.


He said processes accessing more than 4 gb, not total memory - aren't individual processes are still limited to 4 gb of memory with PAE?


I don't know the technical reason, but most 32 bit apps on Linux are limited to 2GB (2^31 bytes).


As jsprinkles alluded to in his post, the 2GB limit (or 1GB or 3GB, depending on kernel configuration) is to allow space for the kernel.


Less depending on where the kernel split is. 3 GB under Linux usually.


If you want to upgrade to 11.04 with a PAE kernel and proprietary Nvidia drivers, be careful: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug...


I find that in order to run Eclipse properly with lots of plug-ins, a fairly big project and Tomcat running at the same time you NEED 4gb. Yes, Java uses a lot of memory but I have 9 gb in my desktop so I'm just fine thanks. 4gb dimms are available for about $54, according to Pricewatch, so quit complaining.


PAE kernel is really only useful in the special case that you have some ancient 32-bit server hardware that supports > 4GB. Anyone else over 4GB should run 64-bit.


32 bit "wastes less memory":

http://journal.dedasys.com/2008/11/24/slicehost-vs-linode

At least for some things, in my experience.


For almost every processor architecture going to 64 bits slows things down due to increased memory usage since very few programs need 64 bit integer addition. However, in x86 the transition to 64 bit doubled the number of architectural registers to 16, and so actually resulted in a speedup.


Hypothetically a 64-bit application could be designed to save space by hacking together a sort of "near pointer/far pointer" system by using native 64-bit reference pointers and 16-bit or 32-bit offsets from them. This would save on a lot of the space used for storing pointers to nearby data.


For another example, Redis uses much less memory per key when compiled for 32-bits.


May improve cache hit rates, but my Dell laptop running 64-bit version never hits the swap partition unless I open a couple Eclipses or do something equally stupid.


Most older machines and many new machines aren't 64 bit. All 64 bit x86 machines will support a 32 bit x86 OS. Many people aren't sure about what's inside of their computer. That's why it's the default.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: