[sf-lug] use 32 or 64 bit on 64 bit capable hardware: Re: installing minimal debian and building on that
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Sat Dec 8 13:05:22 PST 2018
Another factor to consider.
For many/most distributions, support of 32 bit ("i386"), etc.
is waning, or has already been dropped.
Debian, however, supports more distributions than any other
Linux distribution, so Debian may continue to support 32 bit
"i386" for quite some while to come, but even given that,
as things move more and more to 64 bit, 32 bit will become
less well supported - if nothing else, due to the relative
rareness / lower numbers, of installations, etc.
Note also that Debian's i386 no longer supports the Intel i386
CPU - minimum CPU requirements have slowly crept up over the
years, for current Debian stable, presently, see:
https://www.debian.org/releases/jessie/i386/ch02s01.html.en#idp61968064
So, ... if you have hardware with not much RAM (<= 4 GiB) and won't
be expanded/upgrade beyond that, and maybe also aren't planning to contiue
using that hardware for all that many years, then 32 bit *might* be
the better choice.
On the other hand, if the system isn't squeezed for RAM resources relative
to needs, and even if it is and may continue to be <= 4 GiB, but if you
want to keep running same OS on that same hardware for a quite long time
(say 5 to 10 years or more), in such a case, one may be much better off
going with 64 bit, as that's much more likely to continue to be well
supported 5 to 10 or more years down the line ... whereas that may not
be so much the case for 32 bit.
Also, with Debian, upgrades are pretty dang easy (at least
compared to many other distributions) - and including major
version upgrades. However, going from 32 bit to 64 bit ... not
so trivial ... yes, doable, but at least thus far relatively
challenging, and not officially supported (yet? ... Debian may at some
point add official support of switching from 32 to 64 bit of an
installed system).
See also:
https://www.wiki.balug.org/wiki/doku.php?id=system:32-bit_to_64-bit
I've also heard some various bits about Raspbian i386 ... so may be
fair bit of open question how well 32 bit will be supported on at least
some Linux distribution(s), and for how long into the future.
> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] installing minimal debian and building on that
> Date: Sat, 8 Dec 2018 11:41:58 -0800
> Quoting Alex Kleider (akleider at sonic.net):
>
>> I've been following the discussion of Desktop and window manager
>> options with interest and would like to try my hand at beginning
>> with a minimal (terminal only) installation and then gradually
>> building a 'to suit my needs' system.
>
> Coolness.
>
>> My first hurdle is which of the following to choose:
> [...]
>
> cat /proc/cpuinfo:
>
> [...]
>> model name : Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz
>
> x86 family, which narrows it down to IA32 (which Debian calls 'i386')
> or x86_64 (which for historical reasons Debian still calls 'amd64')
> architectures. We could look up that processor on the Internet to find
> out if it is x86_64-capable, but instead we can determine this from the
> CPU flags:
>
>
> [...]
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>> syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni
>> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1
>> lahf_lm kaiser tpr_shadow vnmi flexpriority dtherm ida
>
> The flag 'lm' stands for 'long mode', indicating that this is x86 with
> 64-bit extensions, i.e., x86_64, which Debian calls amd64. So, that
> would be the binary image that leverages the Intel Core 2 Duo's ability
> to do 64-bit memory addressing. But let's talk for a moment about
> memory.
>
> The main benefit of x86_64 over IA32, aside from increasing problems
> from the approaching 32-bit Unix epoch
> (https://en.wikipedia.org/wiki/Year_2038_problem) is the ability of
> 64-bit CPUs to address dramatically more RAM. 32-bit CPUs are limited
> to a 4GB possible address space, Because of tricks required such as
> reserved stretches of the memory space, the effective free RAM available
> to the OS on a 32-bit CPU can be a bit less, even if there is 4GB
> physical RAM available.
>
> By contrast, with a 64-bit CPU, dramatically larger total addressable
> RAM is possible. In theory, this could be 16.8 million terabytes of
> memory, or 2^64 byte, but real-world motherboard implementations always
> have (so far) had limits imposed elsewhere in the hardware that lower
> the limit to something that's very spacious but not _that_ staggeringly
> high.
>
> https://stackoverflow.com/questions/8869563/how-much-memory-can-be-accessed-by-a-32-bit-machine
>
> So, cutting to the chase, that means you should always use an x86_64 OS
> and applications if your x86 CPU has the 'lm' flag indicating 64-bit
> capability, right?
>
> Well, sorta. It depends. Most cases, the answer would be yes. But
> consider a x86_64 machine that has 2GB total RAM and you're certain it
> will never have more. In that case, the theoretical ability to address
> more than 4GB of RAM is never going to be used, so you might consider
> for a while running an IA32 build, at least until problems from the
> approaching 32-bit epoch in 2038 become prominent.
>
> What's the advantage of an IA32 build in that situation? Binaries and
> data require more RAM in 64-bit computing, because 64-bit pointers take
> up more memory and for some other reasons. So, it's a bit of a
> tradeoff. Other subtle aspects are covered here:
> https://en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons
>
> To get the best of all worlds, have an 86_64 CPU, run an x86_64 OS, and
> have lots of RAM. Then, you won't mind the slight bloat from 64-bit
> pointers, and will be able to party on January 19, 2038 like it's 2037.
>
>
>> I think the amd64 version is the one I want but perhaps it's i386?
>
> Almost certainly the former.
More information about the sf-lug
mailing list