On Fri, 11 Mar 2011, Tabby wrote:

On Mar 12, 12:16*am, John Stumbles wrote:

One thing I'm wondering is if it's worth going for a machine with a lot
of RAM - which AIUI requires a 64 bit CPU to access if it's over
2^mumble bytes

http://www.zdnet.com/blog/hardware/c...confusion/3124

This fails to mention PAE, which is still highly relevant for the amounts
of memory we have today. PAE adds four bits to the hardware memory address
on a 32-bit machine, meaning a chip with it can address 16 times more
memory than a purely 32-bit machine, ie 64 GB. 64 GB should be enough for
anyone.

Individual processes can still only address 32 bits' worth, but you can
fit more of them in memory at once, and keep them away from video memory,
etc.

What i don't know is that it's still possible to buy chips with PAE. As
Alex says, it's hard to find a chip that isn't 64-bit these days. Unless
you're buying a netbook.

This is annoying - a system with a 64-bit chip pays the 64-bit tax of
having to have pointers be twice as large (mostly - if you run 64-bit
software at least; an honourable mention goes to Java, which can use
32-bit pointers on a 64-bit system to address up to 32 GB), which means it
makes less efficient use of the memory it has. In the 4 - 64 GB range, a
32-bit CPU with PAE makes better use of memory and memory bandwidth than a
64-bit one (as long as you can live with the 4 GB limit on processes). On
the flip side, the 64-bitness of the registers only gives a speed boost to
code that specifically needs to manipulate wide operands - cryptography,
scientific computing, perhaps some SIMD-based graphics operations. For
most use today, 32-bit+PAE should be faster than 64-bit. And yet, the
market has moved almost entirely over to 64-bit. Grr.

- and running some sort of virtualisation s/w so I can run different
OSes or versions of an OS simultaneously rather than multi- booting.
That way I can try out a new distro or version of my current distro
without sawing off the branch I'm currently sitting on. Am I right in
thinking xen is the virtualisation code du jour for Linux distros?

No, i think Xen is a bit of an also-ran now. At work, we use:

- VMWare ESX; only the infrastructure guys use it directly, and seem to
like it, but everything they tell me makes me think it's complete crap (we
occasionally have the virtual DNS server lock up because we're doing a
complex query on the virtual Oracle server; it takes hours to clone an
image even on a RAID array; management is through some runty cut-down
version of Linux running underneath everything)

- VirtualBox; works nicely for simple uses, is awkward for more complex
uses, nicely interoperable with the Mac (ie we can make an image on Linux
and run it on a Mac)

- QEMU/KVM; works nicely, simple and so powerful to manage, does require
unixy skills to make the most of it (last time i used it - the GUIs might
be pretty good now), doesn't have the nice networking options that
VirtualBox does (QEMU pretty much requires a bridged network, which is a
minor nightmare; VirtualBox will do its own virtual network with NAT,
which is lovely)

I prefer the userland-based options (VirtualBox and QEMU) to the
hypervisor-based ones (Xen and VMWare) because they don't involve having
some random dwarf operating system in control of your hardware. The
userland options use a perfectly normal OS as the host, which will mean
less trouble finding drivers, configuring things, etc.

If i was in your position, i would install a sensible middle-of-the-road
Linux on the physical machine, then install QEMU/KVM, and run things on
top of that. I'd use Fedora for the host, because it's solid enough, gets
updates at a good rate, and benefits from Red Hat's ownership of KVM.

Although to be honest, i would probably actually *not* run things on top
of that, because i'm a confirmed Fedora fan!

tom

--
The term Nihilartikel for a fictitious entry originated at the German
Wikipedia but was later identified as a hoax. -- Wikipedia