maximumpc.com SEP 2019 MAXIMUMPC 17
Alex Campbell
OPEN SOURCE
WI
KIM
ED
IA^
CO
MM
ON
S^ I
MA
GE
.^ C
C^ ©
AS
HL
EY
PO
ME
RO
Y
Much Ado About 32
CANONICAL RECENTLY MADE WAVES in the Linux
gaming community by announcing that it would
be dropping 32-bit support from Ubuntu 19.10,
to which Valve announced that it would cease
supporting Ubuntu. What’s the big deal?
Canonical planned to mothball
32-bit support for reasons of
security and stability.If you’re under a certain age, you might not
remember purchasing a 32-bit system or CPU for
a build. The last 32-bit system I bought was my
Asus EeePC—which has an Intel Atom N270—back
in 2009. For most PCs still running today, there’s
a darn good chance that it’s a 64-bit system. Hell,
even a Raspberry Pi or your smartphone is 64-bit.
That’s a good thing: Most desktop systems
today come with at least 8GB of RAM. Most laptops
you can buy rarely have less than 8GB as well.
Because of the limited address range available
to 32-bit CPUs, most OSes don’t have more than
4GB of addressable memory on a 32-bit system.
The advance of 64-bit systems has been partly
responsible for systems with large filesystems,
large amounts of memory, and larger file sizes.
If you’re not up on your computer science, here’s
a quick refresher: A 64-bit system is said to have
264 bits for its largest integer value, equivalent to
about 8 bytes per integer. In comparison, a 32-bit
integer is 2^32 bits, or about 4 bytes. A 16-bit integer
has 2^16 bits, or two bytes.
So the question comes up: If the world of
consumer electronics is effectively 64-bit, why on
earth does 32-bit support matter?
The simple answer is that some programs or
libraries are still distributed as 32-bit. While 64-
bit systems can run 32-bit programs, it requires
some translation, because of the differences
in memory addresses and other programming
nuances. This is why a 64-bit Linux systemrequires a slew of 32-bit libraries
to run a 32-bit program. The
collection of libraries needed for
32-bit compatibility is essentially
a copy of 64-bit versions that may
already be on the system. This
means that you could potentially
double the storage requirements
for the system’s libraries at worst,
and increase the complexity of the
installed system at best.
What started the hullaballoo in
the Ubuntusphere was the notion
that 32-bit packages and libraries
are rarely used, and by extension,
rarely patched or updated. (Again,
few people actually run native 32-
bit systems.) Because there aren’t
that many eyes looking at the 32-bit packages or code, Canonical
planned to mothball 32-bit support
for reasons of security and
stability. In a blog post, Canonical
specifically cited Spectre and
Meltdown as vulnerabilities that
have no mitigation in 32-bit.
The original announcement
drew concern from gamers and
creatives (using Ubuntu Studio)
who rely on 32-bit compatibility
to run key pieces of software.
Valve noted in a post that Steam
and many of the Steam games
available for Linux are 32-bit.
WINE, the Windows compatibility
layer for Linux, also makes heavy
use of 32-bit libraries.
Canonical’s response was to
continue providing access to 32-bit
libraries, but with a warning that it
could not guarantee the security
of a system when running them.
Canonical said that Ubuntu will
work with app developers to deploy
3 2 - b i t p r o g r a m s i n c o n t a i n e r s , w i t h
all the required libraries bundled
with them. That way, a user doesn’t
have to maintain and update 32-bit
libraries from a repo. This will
shift the responsibility for keeping
a library updated from the user
to the app developer.
While 32-bit systems
are a thing of the past
for most of us, there’s
still a large number of
32-bit applications. Until
every legacy program
is rewritten or compiled
for 64-bit, we need extra
libraries to run them.
Old programs never die,
they just require additional
compatibility layers to keep
them running.Alex Campbell is a Linux geek
who enjoys learning about
computer security.