Arch Linux Preparing To Deprecate i686 Support

[JGC_]

When Archlinux was created many years ago, we started with i686. During that time i686 hardware was quite common, x86_64 hardware didn't even exist at that moment. The main advantage of Archlinux was that it was "optimized for i686" so it was "fast".

There's two main reasons to drop i686:
- Developers run x86_64, packages are compiled in a 32bit chroot on an x86_64 buildserver, but nobody tests their i686 packages
- An increasing amount of packages start to utilize SSE, SSE2, SSE3, SSE4, etc instructions. Most of these extensions are available by default on x86_64 but not on plain i686. This software won't run on plain i686 without patching. Examples include some multimedia packages or things like webkit that throw SIGILL all over the place on i686.

i686 is not "optimized" and "fast" anymore. That raises another question: why focus on i686 and not i586? There used to be a community-driven port for i586 that runs on older i586 hardware or the VIA C3 which is i686 but misses the CMOV extension used by glibc on i686. If it's about support for older hardware, i586 is more logical than i686.

[mulenmar]

And another one bites the dust.

I don't even use my i686 hardware anymore -- I don't have enough memory in it to be worth using, since Firefox and Libreoffice practically require 4GB to compile without swapthrashing anymore. Still makes me nostalgic and sad.

[GreatEmerald]

Correct me if I'm wrong, but isn't support for specific CPU's a Linux task rather than an Arch Linux task?

No, it's an Arch Linux task. Distributions are what decides what compiler flags to apply when compiling all the packages, and if you set -march to something that has more instructions than core2, then core2 will not be able to run the code and the code will be faster for everyone else.

[dungeon]

Just curious, how do you get these figures? Just browsing on qa.debian I couldn't find a breakdown by architecture.

Cheers

Search for linux-image-xxx kernels in these files and calculate... but take note there are various 32bit flavors there

Debian 8 supports even i586 , but with Debian 9 i586 is not supported anymore... funny difference, this news should be named Arch drop i686, Debian 9 drops i586 I guess many original Pentium (non-PRO) users crying now, but why should they when 8 is supported till 2020.

And i don't see how this could drop in Debian anytime soon, when if other distros start to do it... we will just increase on these users

On the other side global upstream won't drop 32bit total anyway, as Windows 10 32bit is there with 3 mainstream plus 5 years probably extended remained... so maybe in 5-10 years

Mozilla didn't yet dropped even Firefox support for Windows XP - looong dead horse is still supported there till september this year it seems... What to say - world is crazy, but that is how that is

[franglais125]

Search for linux-image-xxx kernels in these files and calculate... but take note there are various 32bit flavors there

Heh, sounds good. Too bad, I thought there was a breakdown by architecture!

Thanks.

[caligula]

honestly i would deprecate also <core2

Probably the most retarded comment I've seen here. Yea, let's deprecate stuff just for the lulz.

No, it's an Arch Linux task. Distributions are what decides what compiler flags to apply when compiling all the packages, and if you set -march to something that has more instructions than core2, then core2 will not be able to run the code and the code will be faster for everyone else.

The guy was arguing that < Core2 should be dropped. He didn't give any reason. The fun fact is, Core 2 (the 65nm variants) don't have any new instructions vs old Pentium 4 code. It's all the same SSE stuff, VT-x, NX. So he'd want the distro to blacklist computers that run the code just fine, but seem too old? Core 2 (45nm) has SSE 4.1, which is new. But even with SSE 4.1 enabled compilers, not all apps use those. So the code won't be any faster for everyone else.

[leipero]

It's about time, Google dropped support for 32 bit systems, let's be honest here, last desktop CPU's from AMD was Atlhon XP, whole socket 754 is 64 bit, I think even Semprons are (Sempron 64?), if we look in objective way, those CPU's are pretty much unusable for even simple web based tasks. On intel side, Atom? I don't know how capable are the fastest CPU's from that line, but i doubt it is much above Athlon64 scale.

Core 2 Due are still very capable CPU's, for basic web based tasks are perfect, they support 64 bit architecture, so there's no reason to make those CPU's blacklisted, it's unlogical and it would be equivalent of shooting yourself in the foot.

[caligula]

It's about time, Google dropped support for 32 bit systems, let's be honest here, last desktop CPU's from AMD was Atlhon XP, whole socket 754 is 64 bit, I think even Semprons are (Sempron 64?), if we look in objective way, those CPU's are pretty much unusable for even simple web based tasks. On intel side, Atom? I don't know how capable are the fastest CPU's from that line, but i doubt it is much above Athlon64 scale.

Core 2 Due are still very capable CPU's, for basic web based tasks are perfect, they support 64 bit architecture, so there's no reason to make those CPU's blacklisted, it's unlogical and it would be equivalent of shooting yourself in the foot.

There are few generations of Atoms. The first ones have pretty weak CPUs with in-order execution, which is comparable to weaker ARMs. The later ones have OoO execution (since Bay Trail?). Still, the power comes from efficient co-processors (iGPU, video decoders, accelerated instructions, e.g. SSE, AVX, AES), not from the basic execution engine. So the platform pretty much needs good drivers since it can't decode videos in software.

I'm pretty sure that old ~100W TDP high end CPUs (even 32-bit single cores) can be faster than Atoms especially when overclocked and used with modern external GPUs. A 5W SoC can't really compete with a 100W CPU and a 200W discrete GPU, both having dedicated wide multi-channel memory buses. Especially now that GUI toolkits are moving towards HW acceleration and all video is accelerated, there's little need for efficient CPUs outside games and stupid JS heavy web sites.

[vsteel]

For those who just blare "yeah, kill non-64bit-x86 with fire": You have no clue. Or you are too young. Or both.
There are still enough machines out there doing a fine job "even" with a "lowly" 32bit x86 CPU. Automates, embedded systems, machines in private households, boxes driving expensive measurement devices in laboratories... It's good that there are still some who will support it.

If you are older and around those expensive lab machines and industrial equipment, then you know that on those boxes software doesn't get updated. It chugs along quietly, I am still around equipment that is chugging along on windows NT 3.5.1 and Solaris 2.6 No reason to upgrade, it does what it is supposed to do and no one wants to take a chance it breaks.

If you have nostalgia or need an older box, it isn't like the current versions of software are going to stop running.

[geearf]

i686 is not "optimized" and "fast" anymore.

Would you say that x86_64 is now?