Dropping i686 support

Allan · 2013-02-04 10:08:43

I don't care about upstream support. I am talking about Arch Linux developers. The vast majority don't run i686. The vast majority of i686 package in our repos are uploaded without any testing.

olive · 2013-02-04 10:31:44

Allan wrote:

I don't care about upstream support. I am talking about Arch Linux developers. The vast majority don't run i686. The vast majority of i686 package in our repos are uploaded without any testing.

Yes but I think that to have a specific i686 Archlinux bug in a package that compile is very unlikely. You say yourself that your example was due to upstream and not Archlinux specific.

Last edited by olive (2013-02-04 10:31:56)

Allan · 2013-02-04 11:07:06

So... what is your point? It does not matter where a bug that screws over your system that goes unnoticed because lack of testing comes from.

nomorewindows · 2013-02-04 14:13:56

olive wrote:

Just to say that I am using arch on a old i686 machine (with 2Gb of RAM) (old Celeron M 1.6 Ghz). This works perfectly fine. Recent Gnome3 is a little slow (although it works) but Xfce works like a charm. Since I don't like Gnome3 anyway, I do not see why I should upgrade to run something that I don't like. I am sure it is possible to run Arch on older machines. This machine run Firefox Libreoffice and all modern softwares without any problems of performances. I am glad to read that Arch will continue to support i686 machines and hope this is true. Moreover I think that 32 bits processor are still released now (in some notebooks). I think that supporting i686 at least for 5-10 years after the latest i686 processor was manufactured is a good idea.
A minority of people seem to think that dropping support for i686 is "bleeding edge". I would suggest they use a 128 bits only distribution, then. Surely this will be "bleeding edge"

Are using a 420 or a 520? 420 is i686 and 520 is x86_64. If you actually have a 520, and your motherboard supports it, you can go more than 2GB.

olive wrote:

Allan wrote:
I don't care about upstream support. I am talking about Arch Linux developers. The vast majority don't run i686. The vast majority of i686 package in our repos are uploaded without any testing.
Yes but I think that to have a specific i686 Archlinux bug in a package that compile is very unlikely. You say yourself that your example was due to upstream and not Archlinux specific.

You want to see something that for the most part dropped support is connochaetos. It is geared for <i686, such as i586 (mmx) that doesn't have the cmov instruction that ArchLinux >=i686 requires. Most of these machines still had ISA video cards, but the current xorg implementations is for PCI and AGP devices. If you have a desktop with PCI graphics, and don't have any non-free firmware devices, you could run it. Memory limitations of these machines keeps it from really running all that well. A modern compile of a webbrowser will barely have enough memory to run. Dropping back to RedHat which was more specifically optimized for this class of machinery is a better bet. But then there was something else I found out about even early versions of RedHat, it had Itanium-64 support.

Last edited by nomorewindows (2013-02-04 14:31:56)

olive · 2013-02-04 14:41:56

nomorewindows wrote:

You want to see something that for the most part dropped support is connochaetos. It is geared for <i686, such as i586 (mmx) that doesn't have the cmov instruction that ArchLinux >=i686 requires. Most of these machines still had ISA video cards, but the current xorg implementations is for PCI and AGP devices. If you have a desktop with PCI graphics, and don't have any non-free firmware devices, you could run it. Memory limitations of these machines keeps it from really running all that well. A modern compile of a webbrowser will barely have enough memory to run. Dropping back to RedHat which was more specifically optimized for this class of machinery is a better bet. But then there was something else I found out about even early versions of RedHat, it had Itanium-64 support.

Euh... I was speaking of older 32 bit only machines, not of such antediluvian machine. My 6 years old computer with a Celeron M 420, does have mov (and sse2, pae) support. It does run a modern web browser perfectly (in my case chromium use only 125 Mib of RAM, libreoffice 64Mib of RAM; with my 2Gb of RAM, I have some margin. I can even run 3D apps like Google earth without problem (intel 945GM graphic card). I have done some tests with modern processors and a simple but efficient benchmark tool (pystone in python) show that my processor run only about two times slower than a modern processor per core. So I do not loose that much especially for application that are not easily parallelized.

Last edited by olive (2013-02-04 14:44:15)

nomorewindows · 2013-02-04 14:54:36

olive wrote:

nomorewindows wrote:
You want to see something that for the most part dropped support is connochaetos. It is geared for <i686, such as i586 (mmx) that doesn't have the cmov instruction that ArchLinux >=i686 requires. Most of these machines still had ISA video cards, but the current xorg implementations is for PCI and AGP devices. If you have a desktop with PCI graphics, and don't have any non-free firmware devices, you could run it. Memory limitations of these machines keeps it from really running all that well. A modern compile of a webbrowser will barely have enough memory to run. Dropping back to RedHat which was more specifically optimized for this class of machinery is a better bet. But then there was something else I found out about even early versions of RedHat, it had Itanium-64 support.
Euh... I was speaking of older 32 bit only machines, not of such antediluvian machine. My 6 years old computer with a Celeron M 420, does have mov (and sse2, pae) support. It does run a modern web browser perfectly (in my case chromium use only 125 Mib of RAM, libreoffice 64Mib of RAM; with my 2Gb of RAM, I have some margin. I can even run 3D apps like Google earth without problem (intel 945GM graphic card). I have done some tests with modern processors and a simple but efficient benchmark tool (pystone in python) show that my processor run only about two times slower than a modern processor per core. So I do not loose that much especially for application that are not easily parallelized.

Your 420 is modern, and shouldn't have any problems, because it is i686 class. I586 class machines with modern enhancements don't work so well. Some were limited to about 64MB, others maybe 256MB. They were really cramped. As the machinery gets older, their idiosynchrasies get forgotten.

zrianc · 2013-02-08 10:31:19

I have an x86_64 capable cpu but without VT-x and I have to use virtual machines so inside the virtual machines I am limited to i686.
Current and probably future entry level computers also don't have VT-x so for work that requires the use of virtual machines i686 will still be needed.

I hope that if Arch devs decide to drop i686 support they will officially announce it at least one year before doing it to give time to users to either switch to new hardware or to some other distribution.

Although if such a switch will be made in the near future I would imagine that a project similar to Arch Linux ARM would appear for i686.

FlyingBuzz · 2013-02-11 07:14:50

zrianc wrote:

I have an x86_64 capable cpu but without VT-x and I have to use virtual machines so inside the virtual machines I am limited to i686.
Current and probably future entry level computers also don't have VT-x so for work that requires the use of virtual machines i686 will still be needed.
I hope that if Arch devs decide to drop i686 support they will officially announce it at least one year before doing it to give time to users to either switch to new hardware or to some other distribution.
Although if such a switch will be made in the near future I would imagine that a project similar to Arch Linux ARM would appear for i686.

I have exactly the same situation here at work with several old Xeon servers with only 32-bit guest OS support and really old boxes that people use as terminal clients.
Also some people use i686 systems not to mess around with lib32-* packages.

nponeccop · 2013-02-25 22:23:51

Another argument against dropping i686 is VPS. i686 can be dropped not earlier than VPS with less than 3-4GB become uncommon. These days even major hostings such as Amazon, Rackspace, Linode have offers with less than 4GB. And having x64 instead of i686 doubles hosting expenses.

With https://wiki.archlinux.org/index.php/In … ting_Linux i686 Arch can be installed even if hoster doesn't have a prebuilt Arch image.

mar04 · 2013-02-26 00:21:50

Imho if packages lack proper testing from devs, maybe it's worth considering setting up a web interface for users of [testing] to provide feedback.
Something like http://fedoraproject.org/wiki/Bodhi#Karma
Maybe also an updates policy http://fedoraproject.org/wiki/Updates_Policy

ngoonee · 2013-02-26 00:43:00

mar04 wrote:

Imho if packages lack proper testing from devs, maybe it's worth considering setting up a web interface for users of [testing] to provide feedback.
Something like http://fedoraproject.org/wiki/Bodhi#Karma
Maybe also an updates policy http://fedoraproject.org/wiki/Updates_Policy

You mean like bugs.archlinux.org?

anonymous_user · 2013-02-26 01:17:23

And don't forget the [testing] forum sub-section:

https://bbs.archlinux.org/viewforum.php?id=49

GI Jack · 2013-02-26 04:23:34

hold on. I have not one, not two, but three active machines running the i686 port.

1. two machines, running on earlier intel ATOM cpus, made in 2009 and 2011 respectively, these are both 32-bit machines. they both run arch linux great.

2. an old single core laptop from 2004, that was given to me. it runs XFCE like a champ, and even handles youtube, very usable on arch.

then there is my old p3 custom rig from high school that has LXDE on it, but I haven't booted that in over a year.

there are a good deal of machines out there that are NOT 64 bit. arch probably has one of the best 32-bit compiled binaries there is, and it runs fast and stable on old hardware, which its great for.

please do not nuke i686, its still usefull.

x33a · 2013-02-26 05:07:35

To prove the prevalence of i686, even the latest playstation is an x86 if I am not wrong.

anonymous_user · 2013-02-26 05:50:35

x86 != 32-bit. AMD's Bobcat processors are all 64-bit so I doubt its successor "Jaguar" would go backwards. And besides with 8GB of RAM what would be the point of the PS4 going 32-bit?

Last edited by anonymous_user (2013-02-26 05:50:43)

mar04 · 2013-02-26 06:43:01

ngoonee wrote:

You mean like bugs.archlinux.org?

Something like https://admin.fedoraproject.org/updates
like signoffs from [testing] users, but yeah, in a way it would duplicate bugs.archlinux.org

ngoonee · 2013-02-26 06:52:49

mar04 wrote:

ngoonee wrote:
You mean like bugs.archlinux.org?
Something like https://admin.fedoraproject.org/updates
like signoffs from [testing] users, but yeah, in a way it would duplicate bugs.archlinux.org

There's very little point in 'random' sign-offs, since the whole point of a sign-off system is that those signing off should hold some position of trust. If users are allowed to sign-off, just pushing the packages to [testing] works just as well (if something breaks, noise will be generated pretty fast both on the ML and flyspray).

olive · 2013-02-26 08:33:17

I think that this testing stuff for i686 is not something we really have to worry about, at least for now. devs of course can't test the package on every hardware available and there is a lot of bug are hardware specific (especially things related to Xorg, or printer). I see see i686 as just another hardware. It is much less likely to have a i686 bug in a software that compile than to have a <this-hardware-specific> bug. Moreover a possible i686 specific bug would most probably be due to upstream, the archlinux devs couldn't do anything anyway. For a distribution like arch, not having systematic i686 testing is not a catastrophe. A signed package, prove that the software has been compiled by an archlinux dev and that the 64 bit equivalent works; this is already a lot. Of course it does not guarantees you that it will work without bug, but never will.

Last edited by olive (2013-02-26 08:34:58)

Awebb · 2013-02-26 09:00:08

I use the 32bit version on the netbook, although the CPU is 64bit capable, just for the significantly smaller memory footprint. When I encounter a bug, I try to reproduce it on the desktop machine (64bit) and then perform the usual report procedure. If the bug is not present on the 64bit machine, I add a quick note to the bugreport. As some devs here already stated, i686 specific bugs are relatively uncommon, so if everybody using i686 actively reports bugs, then additional testing by the packagers will not be necessary. If something still happens to break, blaming Allan is always an option.

x33a · 2013-02-26 09:43:21

anonymous_user wrote:

x86 != 32-bit. AMD's Bobcat processors are all 64-bit so I doubt its successor "Jaguar" would go backwards. And besides with 8GB of RAM what would be the point of the PS4 going 32-bit?

Usually x86_64 is used to refer to the 64-bit version. But apparently, I didn't take a close look at PS4's processor which does happen to be x86_64.

As for the RAM, 32 bit processors can use > 3 GB of RAM, but it is indeed not an ideal thing to do.

kokoko3k · 2013-02-26 12:12:38

i'm using linux-pae for a long time without issues.
The only downside is that a process cannot allocate more than 3GB, but i never really needed that.
Also, several benchmarks proved that there are not performance penaltiesbetween 32bit and 32bit-pae kernels.
Said that, when i need more speed i just recompile the app for my cpu instruction set with appropriate CFLAGS...

nomorewindows · 2013-02-26 13:11:48

Since the x86_64 also comes with its' predecessor i686, that's the biggest reason to leave the i686 intact.

masteryod · 2013-02-26 21:59:05

If devs doesn't mind and it's not a big burden I vote to support i686 for quite some time in the future.

Next topic: ARM support

Last edited by masteryod (2013-02-26 21:59:16)

karabaja4 · 2013-02-27 17:38:36

Awebb wrote:

I use the 32bit version on the netbook, although the CPU is 64bit capable, just for the significantly smaller memory footprint. When I encounter a bug, I try to reproduce it on the desktop machine (64bit) and then perform the usual report procedure. If the bug is not present on the 64bit machine, I add a quick note to the bugreport. As some devs here already stated, i686 specific bugs are relatively uncommon, so if everybody using i686 actively reports bugs, then additional testing by the packagers will not be necessary. If something still happens to break, blaming Allan is always an option.

I noticed this too, can anyone explain why i686 has smaller memory footprint then x86_64?

And it's not negligible, 60mb vs 130mb on cold boot with same configuration.

anonymous_user · 2013-02-27 18:02:38

karabaja4 wrote:

I noticed this too, can anyone explain why i686 has smaller memory footprint then x86_64?
And it's not negligible, 60mb vs 130mb on cold boot with same configuration.

Wikipedia wrote:

The main disadvantage of 64-bit architectures is that, relative to 32-bit architectures, the same data occupies more space in memory (due to longer pointers and possibly other types, and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache utilization.

https://en.wikipedia.org/wiki/64-bit#Pros_and_cons

Arch Linux

#76 2013-02-04 10:08:43

Re: Dropping i686 support

#77 2013-02-04 10:31:44

Re: Dropping i686 support

#78 2013-02-04 11:07:06

Re: Dropping i686 support

#79 2013-02-04 14:13:56

Re: Dropping i686 support

#80 2013-02-04 14:41:56

Re: Dropping i686 support

#81 2013-02-04 14:54:36

Re: Dropping i686 support

#82 2013-02-08 10:31:19

Re: Dropping i686 support

#83 2013-02-11 07:14:50

Re: Dropping i686 support

#84 2013-02-25 22:23:51

Re: Dropping i686 support

#85 2013-02-26 00:21:50

Re: Dropping i686 support

#86 2013-02-26 00:43:00

Re: Dropping i686 support

#87 2013-02-26 01:17:23

Re: Dropping i686 support

#88 2013-02-26 04:23:34

Re: Dropping i686 support

#89 2013-02-26 05:07:35

Re: Dropping i686 support

#90 2013-02-26 05:50:35

Re: Dropping i686 support

#91 2013-02-26 06:43:01

Re: Dropping i686 support

#92 2013-02-26 06:52:49

Re: Dropping i686 support

#93 2013-02-26 08:33:17

Re: Dropping i686 support

#94 2013-02-26 09:00:08

Re: Dropping i686 support

#95 2013-02-26 09:43:21

Re: Dropping i686 support

#96 2013-02-26 12:12:38

Re: Dropping i686 support

#97 2013-02-26 13:11:48

Re: Dropping i686 support

#98 2013-02-26 21:59:05

Re: Dropping i686 support

#99 2013-02-27 17:38:36

Re: Dropping i686 support

#100 2013-02-27 18:02:38

Re: Dropping i686 support

Board footer