
Arch Linux pulls the plug on 32-bit - kxait
http://www.pcworld.com/article/3164876/linux/arch-linux-pulls-the-plug-on-32-bit.html
======
StreakyCobra
It is one of the reasons that makes me love Arch: developers are pragmatic.
They were always in the early birds for taking decision about the future, like
switching to Python3 as default interpreter system-wide, embracing the change
to systemd, and now this.

The rolling release aspect imposes to stay as close as possible to upstream
versions because upstream does not wait on Arch to update their dependencies
to newer libraries versions. This, plus the fact that Arch tries to stay as
close as possible to vanilla upstream packages (i.e. less changes as
possible), force them to be pragmatic about their choices. They prefer to
embrace a change directly when it is happening, encouraging at the same time
to contribute upstream for helping them make the transition, instead of trying
to maintain a legacy compatibility that can only get worse with the time.

For me the picture is simple here: Arch is mostly used/oriented towards
personal computers of power users, and most - if not all - of them are on 64
bit for years now. Instead of wasting efforts to maintain 32 bits
compatibility, they prefer to drop it. Side effect will be that people will be
encouraged to get a modern computer if not already.

~~~
CJefferson
The switch to the 'python' command running python 3, as a non-arch user, put
me off Arch forever. It just broke everything, which had long assumed 'python'
would run python 2.

Not installing python 2, and just python 3, with the name python3, would have
been fine.

Arch put us in a situation where it was basically impossible to run python 2
with a #! line, as some distros hadn't yet introduced a 'python2' symlink yet.

~~~
Latty
I'm an Arch user, and it literally broke nothing for me. Packages were
updated, life went on.

You seem to be complaining because other distros hadn't done the right thing.
I don't see how that's Arch's fault. Are we to hold back for the lowest common
denominator? Do we need every distro to join together and agree to a
switchover date?

There was official guidance from Python on the switchover, this wasn't some
maverick decision. It was just moving forward.

Not everyone wants to be tied to ancient stuff for backwards compatibility -
if you do, it's your job to deal with that.

~~~
rlpb
My Python 2 scripts on Github start with "#!/usr/bin/python", as do many
others. All of these broke for you as an Arch user.

Because Arch did what they did, Python now recommends that Python 2 scripts
start "#!/usr/bin/python2" (or the env equivalent).

> Are we to hold back for the lowest common denominator? Do we need every
> distro to join together and agree to a switchover date?

It's not just other distros; it's the rest of the world, including all of the
scripts that people run but distros don't necessarily ship.

The right way to migrate would be to ship and use both /usr/bin/python2 and
/usr/bin/python3. Leave /usr/bin/python as a symlink to python2 for a while.
Eventually, drop the symlink, but _do not replace it with python3_. Allow
users to opt-in to a compat symlink if they wish. Let stuff catch up. When the
expectation that "python" is python2 has faded, _then_ introduce a symlink
from python to python3 by default, letting users opt-in earlier if they wish.

> There was official guidance from Python on the switchover, this wasn't some
> maverick decision.

No, there wasn't, and yes, it was some maverick decision. It was done without
consultation with upstream.

(I am a non-Arch distribution developer)

~~~
Latty
This just feels like culture clash to me - the whole change to Python 3 was
about accepting the cost of breaking changes to avoid dragging around useless
cruft and bad decisions forever.

The idea that we should then never use `python` to mean `python3` is just so
backwards. Sure, in your corporate environment where backwards compatability
is suepr important, do that.

In Arch, people have a distro that moves fast and breaks things, and we are
fine with that. I'll accept the cost of occasionally having to change a
shebang line (although as I have almost never had to go outside the AUR -
someone else in the Arch community has almost always dealt with this for me).

> No, there wasn't, and yes, it was some maverick decision. It was done
> without consultation with upstream.

Fair enough, I got my timelines mixed up - but to be fair, it was then
ratified as the correct way to do things because the upstream project agreed
with the core idea.

> The right way to migrate would be to ship and use both /usr/bin/python2 and
> /usr/bin/python3. Leave /usr/bin/python as a symlink to python2 for a while.
> Eventually, drop the symlink, but do not replace it with python3. Allow
> users to opt-in to a compat symlink if they wish. Let stuff catch up. When
> the expectation that "python" is python2 has faded, then introduce a symlink
> from python to python3 by default, letting users opt-in earlier if they
> wish.

I don't really see why I should have to do this manually? If you don't want
that behaviour, use another distro. This just feels like you feel like you
should have some say in how other people set up their systems.

If you really hate it so much, don't support Arch - that'd be fair. Trying to
shame the distro for doing it ignores the fact it's the core idea of the
distro to do stuff like that, that's the point.

~~~
rlpb
> The idea that we should then never use `python` to mean `python3` is just so
> backwards.

I did not present any such idea. I presented a sane migration path to where
`python` means `python3`.

> ...it was then ratified as the correct way to do things because the upstream
> project agreed with the core idea.

No. It was because the upstream project had their hand forced and are
pragmatic about these things.

> I don't really see why I should have to do this manually?

In my proposal for a sane migration path to the ideal? You wouldn't have to do
it manually. The distribution would do it. As a user you'd be able to override
it to speed up the migration for yourself if you chose; that's all.

~~~
Latty
I chose to run a bleeding edge distro to be on the bleeding edge. Requiring me
to make the changes to be on the bleeding edge manually makes no sense.

Expecting that is as weird as expecting super stable LTS releases to run the
latest-and-greatest of everything.

~~~
rlpb
> Requiring me to make the changes to be on the bleeding edge manually makes
> no sense.

Which part of "You wouldn't have to do it manually" do you not understand?

~~~
Latty
Which part of "I want it now, not in the future" do you not understand?

> In my proposal for a sane migration path to the ideal? You wouldn't have to
> do it manually. The distribution would do it. As a user you'd be able to
> override it to speed up the migration for yourself if you chose; that's all.

I want to speed up the migration for everything - that's why I run Arch. That
'override' is a manual step I don't want to have to do.

------
akoster
It is a shame that many major Linux distributions are dropping 32-bit x86
support. I used to be able to say with confidence that the old laptop or PC in
your garage can run any major Linux distribution, breathing new life into
aging hardware. For example, I have an old ThinkPad T42, which I use to test
out new Linux distros, which incidentally, is currently running Arch. Using
older hardware increases the chances that stable drivers will be available. I
put in the CD (or flash drive), boot up, and everything seems to just
work(tm). Its no speed demon, but its usable. But now with Arch dropping
support for a significant amount of commonly available and being a major, top-
level distribution, I feel I now must make specific recommendations for Linux
newcomers to try rather then have them waste time downloading a large ISO,
transferring it to a flash drive or disc, to find they are unable to boot up
with it. This may cause users to give up before even giving Linux or open
source software an honest try.

Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison
and Intel Galileo boards). Does this mean Arch Linux wont be an option for
these devices?

Despite RHEL 7/CentOS 7 not supporting 32-bit x86, there is now a community-
led effort to port it to 32-bit x86. I wonder if Arch would consider doing the
same (supporting 32-bit x86 as an alternative architecture).

~~~
kogepathic
tl;dr - due to a CPU bug, you can't run normal i686 distributions on the Quark
anyway, and support in mainline Linux is still shit 3 years after release.

> Also, I wonder what this means for the Intel Quark SoC (found in Intel
> Edison and Intel Galileo boards). Does this mean Arch Linux wont be an
> option for these devices?

I have a device based on the Quark SoC. Support is abysmal for this SoC,
especially considering it's been on the market for 3 years (2014). Intel has
clearly abandoned this market segment since their repeated headlines of new
Quark SoCs has totalled exactly 0 new product launches since 2014.

In mainline Linux I can't use the onboard Ethernet because of some
modifications Intel made to the stmmaceth module that weren't pushed upstream.
The internet is full of people trying to run newer versions of Linux on their
Quark hardware and Intel telling them to use old Yocto Linux BSPs [0] because
they can't be bothered to clean up and push their code upstream (or upstream
refused to merge it, I don't know and haven't checked).

Also the Quark is affected by the F0 0F bug, so you can't run normal
distributions on it because processes will segfault. [1]

> It might solve this issue for Intel Quark, but it would break for any
> multicore processors. This is not something acceptable.

Honestly I'm not sure why anyone would want to buy a Quark based system.
Support is bad, performance is terribad, and power consumption is also
terrible (my Quark system idles at 7W, and consumes 2W when in S5 "off"
state). You would be very wise to look for an ARM instead of choosing this
dumpster fire of a CPU.

[0]
[https://communities.intel.com/thread/105047](https://communities.intel.com/thread/105047)

[1] [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=738575](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=738575)

~~~
akoster
Thanks for your post (and tl;dr comment too - I need to work on being more
concise :-). I own no Quark powered boards but have some friends who do. It's
a shame that they fall into the category of boards with poor software support
(and even more of a shame since they are based off the Intel architecture). I
own a few raspberry pi's and have been extremely pleased that even my rPi
model B+ from 2012 still gets support and updates (and hopefully will for a
while longer now that the rPi zero exists with similar hardware). Friends
would brag about the faster or cheaper O-droid, Pine-64 or Banana-pi, but with
dismal software support, I couldn't justify even a descent performance boost.
This reminds me of the little I know of the Android ecosystem, where a tablet
I bought in 2013 is still stuck on Jelly Bean, while my 2012 iPhone 5 still
gets updates. I wish there was some sort of regulatory label put on these
devices (or boards) that would clearly state how many years of support they
would commit to.

~~~
kogepathic
> I wish there was some sort of regulatory label put on these devices (or
> boards) that would clearly state how many years of support they would commit
> to.

As someone who owns a Raspberry Pi, PandaBoard, BananaPi, Orange Pi, and Intel
DK200 I've learned this important life lesson:

Always assume that the most support you'll ever receive for the board is on
the day you buy it.

Apart from the Raspberry Pi, no one else gives half a shit to fix bugs or even
provide distro updates for their hardware.

Cheap Chinese boards are even worse for this. They'll typically take the SoC
kernel (an ancient version several years out of date with the worst patches
you've ever seen) and roll some shitty old distro around it (e.g. Ubuntu
14.04, Android 4.4).

A good recommendation for people looking to buy a board is to look at the
Armbian [0] or Arch Linux ARM [1] supported hardware (read the notices!!!) and
buy that.

[0] [http://armbian.com](http://armbian.com)

[1] [https://archlinuxarm.org/](https://archlinuxarm.org/)

------
dhekir
One thing that concerns me is packaging desktop virtual machine images for
easy reproducibility.

We realized that some users do not (or cannot, due to security policies) turn
on VT-x/AMD-V in their machines, and therefore Virtualbox and VMWare Player
cannot run 64-bit guests.

So we had to make 32-bit virtual machine images for them. If popular distros
stop supporting 32-bit, we will have a harder time packaging such images,
since we'll have to use a different distro for them, with different package
names, settings, etc.

~~~
ryanlol
This just means that you'll need to charge your customers more for supporting
such obscure configurations.

~~~
ethagnawl
It also means they'll have fewer customers running 32-bit builds.

------
Koshkin
Good for Arch, I guess. Still, there's plenty of uses for 32-bit platforms.
Also, much of the attractiveness of Linux (the kernel) and the GNU software
has always been in their excellent support for various architectures and
platforms.

Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t)
prompted by the inflated need in large address spaces lead to an ever more
increasing demand for memory (due to in-memory objects being now bigger in
size)?

~~~
gsnedders
> Incidentally, wouldn't the exclusive use of 64-bit pointers (and size_t)
> prompted by the inflated need in large address spaces lead to an ever more
> increasing demand for memory (due to in-memory objects being now bigger in
> size)?

Yes. This is the reason why some people have pushed for "x32" support, and why
Linux 3.4 and above supports it (tl;dr: x64-64, but with 32-bit pointers: you
get all the advantages of x86-64 without the pointer bloat).

~~~
i336_
Except processes can't use >4GB virtual memory.

But wait. This could actually work out really well for Chrome, since it's
multiprocess, and each process will likely consume <4GB.

That is really cool.

I've been wondering why Chrome on my T60 (64-bit but only 3GB RAM visible due
to chipset stupidity) is noticeably, perceptibly _slower_ and far more ready
to swap itself to death than on my T43, which practically flies. (The T60 has
a Core2 T7200, the T43 a Pentium M.) Bigger pointers sounds like a very
interesting theory, especially considering the "enterprisey" nature of
Chrome's C++ code - piles of vtables and pointers to pointers to callbacks to
pointers to...

------
nebulon
Will be interesting if a part of the community "forks" arch like they did for
16bit back then. However lowarch is apparently also dead by now:
[http://www.lowarch.org/](http://www.lowarch.org/)

I still have that installed on a i386 machine, but not booted since years.

~~~
creshal
> I still have that installed on a i386 machine, but not booted since years.

Did it even work usefully? While Linux itself retains backwards compatible
drivers for a long time, X.org and others aren't quite as diligent.

E.g., five years ago I could not run any up to date distribution on Pentium 4
era notebooks with anything more than unaccelerated VESA framebuffers, because
there were no compatible drivers for their integrated graphics card any more.
(At the same time, we still had Pentium 4 _servers_ in production use!)

~~~
stinkytaco
I feel like this is a place where slackware shines. They keep pushing out
security updates for years.

------
nailer
Other tech folk have always talked about 32 bit support as a necessary evil
since smaller types mean less memory.

The _complexity_ of managing a secondary 32 bit environment has been worse
than the memory usage of 64 bit apps for a very, very long time.

~~~
joaomsa
That need has been met by the x32 ABI for some time now, it combines some of
the best parts of the x86_64 arch with the lower memory consumption of 32bit
(still limited to 4gb max memory though)

[https://en.wikipedia.org/wiki/X32_ABI](https://en.wikipedia.org/wiki/X32_ABI)

~~~
hawski
Does anyone use x32 ABI though? I once asked and only crickets answered. I'm
experimenting with my own Linux distribution and was wondering if it is worth
the time investment.

------
gkya
The original news on Archlinux.org: [https://www.archlinux.org/news/phasing-
out-i686-support/](https://www.archlinux.org/news/phasing-out-i686-support/)

------
TazeTSchnitzel
32-bit is sometimes used on new hardware to save memory. For example, my
Windows 10 tablet has only 1GiB of RAM, and I assume that's why it was pre-
loaded with the 32-bit version.

I doubt Linux distros are generally targeting these devices, though.

------
jasonkostempski
FreeBSD did this too, right after I had just setup a local Minecraft server on
an old Pentium D. It's a shame because it works perfectly for that purpose and
now it'll just have to sit on FreeBSD 10 for the rest of it's life. I don't
plan expose it to the outside world so that's OK for me, but surely 32-bit
machines still have a purpose.

~~~
ftigeot
As far as I know, the only BSD operating system to drop 32-bit support was
DragonFly, back in 2014:
[https://www.dragonflybsd.org/release40/](https://www.dragonflybsd.org/release40/)

~~~
JdeBP
PC-BSD dropped it with version 9.2, in 2013.

* [https://blog.pcbsd.org/2013/06/pc-bsd-status-update/](https://blog.pcbsd.org/2013/06/pc-bsd-status-update/)

------
pavanky
The maintainers are dropping a hard requirement for 32 bit and asking the
community to step up if they want to. 32 bit packages can and will continue to
be still packaged under archlinux perhaps from [community] instead of [core]

------
shmerl
What about supporting older 32-bit applications? Without 32-bit support, there
won't be any way to run 32-bit games in Wine for example, unless Wine will
somehow rewrite it all to work with underlying 64-bit libraries.

~~~
LukeShu
The [multilib] (ie, 32-bit libraries on 64-bit installs) support isn't going
anywhere.

~~~
shmerl
That's good! Though since the focus on 32-bit will decrease, it's possible
that support for it in libraries will start deteriorating, and in the long
term it can become an issue for use cases like Wine.

------
40acres
Off topic: I've been in the market for a new laptop that runs Linux, I've
never had a PC that ran Linux (closest thing was a Macbook running MacOS, I'm
also discounting my work laptop that allows me to VNC into SuSe). After doing
some research it seemed like Arch Linux might be a good fit, it seems like a
very minimal OS that allows for great customization. However I'm unsure how
user friendly it would be for someone who has never installed a Linux distro.

Can anyone comment about their experiences with moving to Arch and the
learning curve?

~~~
arca_vorago
"Can anyone comment about their experiences with moving to Arch and the
learning curve?"

To me arch is designed to force you to learn the guts of your system, so it
has a relatively high learning curve but it is one that pays dividends in the
form of understanding what your system is doing and how it is setup. (this
aside from the side-effect of keeping it debloated and therefor fast)

Honestly, what I would suggest is this:

Step 1:(if you have the time) go through a full arch install. Now format and
do it again without following the guide. Now maybe do it one more time.

Step 2: (if pressed for time and/or lazy) Install Manjaro. I distro-hop
frequently, and while I generally try to use debian on servers, for
desktop/laptop use I have gone from Arch to Suse to Fedora, but I recently
gave Majaro a shot, and I can honestly say next to Suse it has the easiest and
most graceful linux installer I have ever seen (beating even Ubuntu). I
generally don't like using Mint-like everything in a box distros, but the
slimness of Arch along with the Just works of Ubuntu/Fedora/Suse I am finding
it highly likely Manjaro is going to be my distro of choice for a long time to
come. If in doubt, you can always just fire up different installs in a
virtualbox first.

------
v0v
Any one still wanting to install 32-bit with XFCE and easy GUI installer,

see; [https://manjaro.org/get-manjaro/](https://manjaro.org/get-manjaro/)

Or simply use "Manjaro Minimal Net Edition (32-bit)"

Another alternative is to use BlackArch (32-bit)

[https://blackarch.org/downloads.html](https://blackarch.org/downloads.html)

------
ChuckMcM
This is unfortunate. One of the nice things about Arch was you could count on
it to run on the older (32bit) systems.

------
nspattak
Damn, am I the only one who doesn't feel long ago when we were looking for
64bit distributions to test owr brand new opterons? Arch did not exist at the
time(if I remember well).

------
crimsonalucard
I love the rolling release aspect of arch but I'm looking for something more
user friendly. Anybody know of a good linux distro that is user friendly and
has rolling releases?

~~~
fiddlerwoaroof
Debian testing might work. I don't know if it is technically a rolling release
distro but it stays up to date. Also OpenSuse tumbleweed. And there's a
similar Fedora distro: rawhide, maybe?

~~~
EdwinHoksberg
Why use testing instead of unstable? (genuine question)

~~~
fiddlerwoaroof
I don't really know, I haven't seriously used unstable. That being said, I
like testing because the packages are generally new enough for my purposes but
they've also had more vetting, so I don't have to worry about a broken system
as much.

------
imode
welp, guess I'm switching to debian.

I have a few 32 bit machines under my watch, and this is disheartening.

~~~
anonbanker
Switch to Devuan instead, unless you really have a thing for systemd.

------
solnyshok
they did not mention anything about Arch on 32-bit ARM. Still plenty of
devices in the wild

~~~
coldpie
The ARM ports have never been "official" ports of Arch Linux. This
announcement is about dropping one of the official ports, the 32-bit-only
version.

------
mhd
Bad news for my old X60 Thinkpad (still the best laptop form factor I've ever
owned).

~~~
LukeShu
If you're interested, Parabola (an Arch derivative) is continuing i686 support
pretty much solely because so many of the Parabola developers love their X60's
(which is largely due to Libreboot support).

------
yAnonymous
Reposted with added "upstart" so Arch fanboys can't nitpick their way out of
this.

~~~
morganvachon
> _stuck to SysVinit and told users "you want Systemd, make a package" until
> long after the big distros had made the switch_

Bullshit, Arch was one of the first to switch to _systemd_ as the default way
back in 2012. The only "big distros" that switched before Arch were Fedora
(obviously since that's where it came from), Mageia which is based on Fedora,
and OpenSUSE (but not SLES). The next distro to switch was CoreOS a full year
later, and Debian didn't switch until 2015.

I'm not a fan of Arch anymore either, but if you're going to disparage any
distro, at least get your facts straight.

Edit: Getting my own facts straight: Mageia was based on Mandriva, not Fedora.

