[Arm-dev] Gigabyte MP30-AR0

[Gordan Bobic]

On 2016-02-29 15:58, Jon Masters wrote:
> Indeed. The architecture contains a 32-bit backward compatible
> component (that is optional in 64-bit ARM servers[0], but included in
> the one that you are using) and it is technically possible to install
> the libraries side by side. However the upstream that Cent is using is
> intentionally engineered never to support that case. It sounds harsh
> now, but there is no 32-bit server legacy, we have 32-bit VMs, you
> could build a 32-bit container if you really wanted, and in a couple
> of years we will all be wondering why we ever cared about 32-bit in
> the first place on ARM servers.

If a container should work, why does chroot not work? I don't
particularly care about running things side-by-side (as per the
enormous in-everyone's-face precedent of x86/x86-64), but why would
running an armv5tel guest in a chroot not "just work"?

> [0] That was my doing. It is time to move on from 32-bit and not
> create a legacy, dragging everyone's power/performance efficiency down
> having to implement expensive 32-bit backward compatibility that
> people don't actually need. Recompile the software and move forward.

It's far too easy to take the moral high ground when you aren't in
need of closed source software that you cannot just recompile.

Until a couple of months ago, the only Plex Media Server variant
available for ARM was armel (ARMv4 soft-float). It'll likely  be a
while before they provide an aarch64 PMS binary.

Additionally, it would be really handy to be able to use a big
aarch64 machine with tons of RAM for building 32-bit ARM packages.
Big compile jobs on the pitifully underpowered and under-RAM-ed
are increasingly painful, particularly the well known bloatware
such as web browsers (EL6 Firefox brings it's own GCC the build
process has to build first before using it to compile FF),
LibreOffice and others.

Gordan