Farewell i686!

The first 64 Bit x86 CPU was released ten years ago: the AMD Opteron. Intel followed with compatible processors about one year later. Another two years later, in 2006, a first port of Arch Linux to the x86_64 platform was available. Starting outside the official repositories, the new architecture was merged into the Arch project and became a first class citizen within the following years. Right from the start it was designed as a pure 64 Bit system and kept in sync with the i686 tree. That also meant no multilib support at first and every package was compiled for x86_64.

Of course getting there was not that easy. Our repositories and tools like pacman did not have any concept of different architectures. While most software would just work fine when compiled for x86_64, we occasionally ran into issues that were specific to the 64 Bit architecture.

Years later the relation between 32 and 64 bit architecture seem to have switched roles.  Developers have chosen x86_64 as their primary platform, our i686 packages seem to get tested by less users and we see issues specific to the 32 Bit architecture. We recently relaxed our signoff policy for i686 packages in order to counteract this trend and avoid holding back development due to lack of testing.

To back these observations with some numbers, I analyzed the architecture submitted by users via pkgstats over the past few years. Even if we assume that these data are not absolutely accurate and I could not find all the data gathered between 2009 and 2010, the results are clear: While the x86_64 version of Arch Linux was installed by only 20% of our users in 2008, its usage grew to 80% in 2013. It is fair to say that within the next years i686 usage will fade away.

Architecture Usage by Date

Architecture Usage by Date

For a few month we also collect data about the actual CPU architecture users have. Right now about 93% operate a CPU that would be capable of running a 64 Bit system. There is not much data yet, but it seems to be a slowly rising number.

CPU Architecture Usage by Date

CPU Architecture Usage by Date

We are pretty close to the point where i686 Arch Linux installations have been almost completely replaced by x86_64. This of course means that it might no longer be practical to provide support for an architecture that is barely used. The question is not if 32 bit support might be dropped,  but when.

Don’t Panic! I don’t see us dropping i686 support this year, but I would not dare to predict anything beyond that date. As always these decision are not based on business or politics. We will see when i686 usage will drop below a critical number and developers loose interest in packaging and supporting that architecture.

26 thoughts on “Farewell i686!

  1. we use arch based i686 development VMs. Using a 64-bit guest would require all host machines to have either a 64-bit host OS or the required CPU extensions. Therefore we cannot move to a 64-bit install at the moment.

  2. I’m part of the minority still needing i686 too 😉 I’m running Arch on an eeePC 701 as my internet router / local dhcp+dns server and its CPU doesn’t support x64 as far as I know.

    Thanks to this early announcement I guess I’ll start saving now for a x64 capable replacement ! 🙂

  3. What are the actual numbers? I mean, how many reports are actually 100%? It is clear to me that in 2007 there are probably less reports than in 2013. Could please provide a graph of the amount of reports per year or a link to that data? That would be intresting for me.

  4. Is it worth keeping a second arch, so that if in the future if say an arm port is desired, all the arch linux specific programs and infrastrucure are in a capable state, or is this to much work on an off chance

    • The ARM architecture will be interesting in future. ATM it lacks just capable hardware (Laptops,Desktops and Servers). Supporting ARM is likely more work as it is completely different while i686 and x86_64 share a lot; including the fact that you can nativly run and build i686 programs on a x86_64 system.

  5. A good compromise is to continue to support some packages for i686 like the ones useful on servers (I have an i686 Arch Linux server).

    • In our current workflow and tool setup this might actually introduce more work than just support both architectures equally. The overhead of maintaining i686 in parallel is not that high. That’s why we still can easily support it even with such a slim user base.

    • My old Atom based netbook actually supports x86_64 just fine. Though I know that the first generation of devices does not. x32 requires a x86_64 CPU btw.. I assume you meant i686.

  6. Time is moving so fast… I still don’t have any x64 machine…

    I think this is a form of planned obsolescence. I don’t like seeing linux distros dropping i686 support one after the other, this makes it sound like it is time for everybody to upgrade their computers, when they could have spent their money elsewhere. Computers bought 10 years ago would still be perfectly usable by anybody, if it wasn’t for all the decisions made by developpers who tink it’s not worth it to support anything that’s more than 3 years old.

    I understand the motivations behind this decision that will come sooner or later, but I don’t like the message it sends.

    • Arch is a community project and nobody gets paid to create packages. So dropping i686 (which again, is not planned at this point) will not be a business decision. We just don’t have the hardware, time, resources and user base to support it. Why should we invest anything in a system we don’t use on our own?

    • Apply to be a TU or dev. “Lack of people running i686” will be a non-issue if enough people like you or I join.

  7. Ok, this is the begining of the end of i686
    this entry and that post on the forum open the question and all

    In thesame way that dev lie about maintain forever initscripts

    PD: Initially I read firewall

      • in any case, efi i386 in a 64bit CPU exist and are used widelly with Win8 install
        the problem whit that is that efi i386 not boot (in my case) a 64bit kernel forcing using Bios-GPT as way to boot 64bit kernel but this remove the whole adventajes of efi

        in any case you can put a deadline for drop it like 203x

        • Afaik UEFI requires x86_64. Are you talking about older Apple hardware? If you are indeed using UEFI and you cannot boot any 64 BIT system, this sounds like a bug to me. Even Windows wont boot then.

          • Samsung N100SP released on 2010 aprox is a efi i386
            additionally you can read on the forum one or 2 reppor of peoples that running moren (sirca 2012) efi NON-mac efi machines discover that they efi are i386

          • Well, technically it is not UEFI then. Right now we already only support EFI on x86_64 anyway.

            But you should still be able to boot in BIOS mode which is probably a good idea anyway especially with such early EFI implementations.

            However, this does not really change the actual problem here. Less and less developers and users will run i686 hardware and support will get more expensive.

            Edit: Turns out I was not accurate here. So an UEFI implementation might be 32Bit and as such wont load a 64Bit OS. I am not sure if these systems are widely used though as Windows does not support this; at least to WP and MS websites only x64 versions of Windows can boot via UEFI.

          • directly from the botloader say that is unable to load efivars due kernel mitmatch with uefi (yes say uefi and CMOS name thi: UEFI compat mode and give 2.3.1 as version)

            anyway the N100SP is uefi, can run Meego in uefi mode but only in 32bit kernels

            but yes, anyway i386 remain having a grat issue in t_time at y2k38 (38 right?)

  8. Instead of I386, are there any plans to integrate Arch Linux ARM into the main Arch as soon as it gets more widely used?

Leave a Reply

Your email address will not be published. Required fields are marked *