Dropping i686 support

Allan · 2012-08-29 08:34:20

abveritas wrote:

None of the examples I mentioned have even remotely to do with the build-system, it is people making an honest mistake, and catching those before builds move to stable

None... lets link the thread

From: http://chakra-project.org/bbs/viewtopic … 491#p58491

abveritas wrote:

The Swedish build server used has x86_64 installed, most packages that cannot be cross compiled states so in the build instructions, or error out with clear messages about wrong arch/elf class.

Either your build system is completely screwed (cross-compiling i686 on x86_64 instead of a chroot), or you don't understand what cross-compiling is.

ZekeSulastin · 2012-08-29 11:34:53

ElderSnake wrote:

Okay I'll admit I run i686 even though my fairly modern Intel dual core machine is completely 64bit compatible.
The main reason I've been running it is because I have 3GB RAM and I wanted life with Wine and Flash to be as simple as possible as I had some headaches with 32bit libs once. Also I was under the impression with less than 4GB RAM that a 32bit OS would use a little bit less memory than 64bit, but it probably wouldn't matter even on 3GB.

RAM isn't the only reason to use the x86_64 binaries if available - more registers/cpu instructions/etc. are available when targeting an x86_64 base as opposed to i686. There are cache considerations to take into account, though, hence the x32 ABI; still, even without that you might see a bit of performance increase ...

Also this, since Linus rants are always entertaining and sometimes quite informative

(The worst problems I've had with lib32 lately are merely folks in the AUR forgetting to specify them; it's pretty painless nowadays imo)

Last edited by ZekeSulastin (2012-08-29 11:36:14)

karol · 2012-08-29 11:50:35

gm112 wrote:

can we please get a CLI-mode installer again

http://mailman.archlinux.org/pipermail/ … 02734.html
http://mailman.archlinux.org/pipermail/ … 02807.html

nomorewindows · 2012-08-29 20:12:00

ZekeSulastin wrote:

ElderSnake wrote:
Okay I'll admit I run i686 even though my fairly modern Intel dual core machine is completely 64bit compatible.
The main reason I've been running it is because I have 3GB RAM and I wanted life with Wine and Flash to be as simple as possible as I had some headaches with 32bit libs once. Also I was under the impression with less than 4GB RAM that a 32bit OS would use a little bit less memory than 64bit, but it probably wouldn't matter even on 3GB.
RAM isn't the only reason to use the x86_64 binaries if available - more registers/cpu instructions/etc. are available when targeting an x86_64 base as opposed to i686. There are cache considerations to take into account, though, hence the x32 ABI; still, even without that you might see a bit of performance increase ...
Also this, since Linus rants are always entertaining and sometimes quite informative
(The worst problems I've had with lib32 lately are merely folks in the AUR forgetting to specify them; it's pretty painless nowadays imo)

Now you and Linus have done it. You've put the whole concept of using PAE as a cheat for what the 64-bit architecture does even though some of us don't have enough memory to really use it. Now we have the whole 32-bit vs. 64-bit issue right at hand. Manufacturers that have recently stopped selling machines with 2GB because of the 32-bit limitations when they included Windows with the purchase. Early 64-bit processors are included with some of these machines, but the memory limitation is still there. I'd like to use more than 2GB of RAM with my 64-bit architecture! Anyhow.

scjet · 2012-08-29 21:20:43

dolby wrote:

I never thought that Allan was serious about this and i hope he's not, but it seems that Chakra beat him to it.
http://chakra-linux.org/news/index.php? … pport.html
With Chakra being a community distro, it is fully shaped by those who are actively working on its development. For a number of reasons explained in this news article The Chakra-Project team has decided, it is best for this project to focus from now on solely on x86_64.
Once again Arch comes second

"...Arch comes second..." second to what 32/64-bit schtuff ?
Chakra isn't "just" about Arch, however 64-bit now does "Lead The Pack, ... !", but there's also/still ARM, Motorola controllers' (rare but magically still available), ..., and other project(s) that will always potentially remain 32-bit/whatever-bit.

When Arch develops fully for "x86_64" which will happen (because obviously even "RedHat/Windows" says so now), eventually-in the far furture, it also doesn't mean other projects(within and without) 32-bit or otherwise won't sprout up -on "their" own.
Cake and eat it too ?, - I think not, but atleast we'll hopefully still be able to choose.
I know that is not much consolation, but by then though, it'll be "no more worries mate", especially regarding this thread, because it'll be 64-bit too, like it or not.
(if it isn't already ?).

In fact, I think retirement should be set at "64", and not "67", but I'm sorry -I'm way off-topic now.

Last edited by scjet (2012-08-29 21:50:34)

masteryod · 2012-08-29 21:33:54

Shark wrote:

Any problems with KDE (x86_64) running on 2GB ram?

Nope, x86_64 system with KDE eats noticeable more RAM but with 2GB you're fine (of course if you don't use akonadi, nepomuk with high memory settings, and for the love of god amarok which can eat tons of ram just for fun of doing absolutely nothing). I would say that 1GB for properly trimmed KDE on x86_64 is right on the edge, where it works pretty nice for "light web browsing" but as soon as you start to do some work, run many apps, browser with more tabs than just couple, maybe flash and you're gonna feel the hell of swapping.

WombleGoneBad · 2012-08-29 22:49:13

FYI - i run 32 bit arch on my (meenee) laptop
I use the 32 bit build because i *need* to use skype, as that is what the people i need to talk to use, and I dont like the idea of 2 sets of libs (space, clutter, confusion )
I just wanted to highlight that the hardware support is not the only consideration.

nomorewindows · 2012-08-29 23:26:37

WombleGoneBad wrote:

FYI - i run 32 bit arch on my (meenee) laptop
I use the 32 bit build because i *need* to use skype, as that is what the people i need to talk to use, and I dont like the idea of 2 sets of libs (space, clutter, confusion )
I just wanted to highlight that the hardware support is not the only consideration.

If you have 64-bits, you can easily have all the capacity of the processor and then run your 32-bit "must haves" in its' own sandbox chroot without rebooting.
My system seems to run a tad bit faster on 32-bits, but earlier kernels would belly up. It's probably not a problem now, but there's other advantages. I can chroot into my 32-bit environment, have a 32-bit PXE client on that same install. I can jumpstart a diskless workstation with a minimal amount of fuss. Micro$oft seems to want to lock down every feature to get you to ante up more $ for their $loppy $oftware and corrosponding licen$es. To do a PXE client with Micro$oft, you have to image a CD for that purpose, why not just use a CD? It can be done, but it seems to be pointless. If you don't have the CDROM in that machine(?), it allows you to install yet another misfit that would already require hard drive. With Linux, the same installation can be reused without much fuss from how it operates. Remember, it is an operating system, not road kill on the side of the cyberspace highway.

jasonwryan · 2012-08-30 03:18:21

nomorewindows wrote:

WombleGoneBad wrote:
FYI - i run 32 bit arch on my (meenee) laptop
I use the 32 bit build because i *need* to use skype, as that is what the people i need to talk to use, and I dont like the idea of 2 sets of libs (space, clutter, confusion )
I just wanted to highlight that the hardware support is not the only consideration.
If you have 64-bits, you can easily have all the capacity of the processor and then run your 32-bit "must haves" in its' own sandbox chroot without rebooting.
My system seems to run a tad bit faster on 32-bits, but earlier kernels would belly up. It's probably not a problem now, but there's other advantages. I can chroot into my 32-bit environment, have a 32-bit PXE client on that same install. I can jumpstart a diskless workstation with a minimal amount of fuss. Micro$oft seems to want to lock down every feature to get you to ante up more $ for their $loppy $oftware and corrosponding licen$es. To do a PXE client with Micro$oft, you have to image a CD for that purpose, why not just use a CD? It can be done, but it seems to be pointless. If you don't have the CDROM in that machine(?), it allows you to install yet another misfit that would already require hard drive. With Linux, the same installation can be reused without much fuss from how it operates. Remember, it is an operating system, not road kill on the side of the cyberspace highway.

Easy there, Tiger.
https://wiki.archlinux.org/index.php/Fo … ng_Systems

masteryod · 2012-08-30 09:29:12

WombleGoneBad wrote:

FYI - i run 32 bit arch on my (meenee) laptop
I use the 32 bit build because i *need* to use skype, as that is what the people i need to talk to use, and I dont like the idea of 2 sets of libs (space, clutter, confusion )
I just wanted to highlight that the hardware support is not the only consideration.

Ok... but you do know that skype works just fine on x86_64 with enabled multilib repo? I'm running it and there's nothing cluttering or confusing about it. Additional dependencies are not that big either, just couple of 32bit libs. To sum up: skype is not deal braker and as hardware is getting better and better, need for i686 is decreasing (around 4GB and more of RAM there is no point of running i686 even with PAE).

WombleGoneBad · 2012-08-30 22:36:19

nomorewindows wrote:

... and then run your 32-bit "must haves" in its' own sandbox chroot without rebooting.

ewww. not for me thanks. i use chroot for cross compilation, but i dont want to have to do that sort of nonsense for just running normal apps.

masteryod wrote:

Ok... but you do know that skype works just fine on x86_64 with enabled multilib repo?

yeah, thats what i'd do if you FORCED me off 32 bit. I actually tried multilib briefly about a year or so back and ditched it when i ran into some issues (not with skype... If i remember rightly it was confusing the compilation of something.)

slint · 2012-08-30 23:33:07

Maybe it should be stated (for instance in the install guide) that x86_64 is recommended, to affect the number of 32/64 bit installs so less people will be fed up when 32 bit support is dropped in a few years.

x33a · 2012-08-31 10:03:07

@ slint

Considering the percentage of Arch users using 64-bit, i doubt that many are unaware of the benefits of it. Others like me stick to 32-bit out of compulsion, so promoting 64 bit isn't really needed in Arch's case.

ronnylov · 2012-08-31 14:55:21

I use 32-bit on a socket 754 Athlon 64 3400+ with 1GB of RAM (it is my htpc running xbmc and tvheadend). I chosen 32-bit because I thought that I would not benefit from 64-bit when having only 1GB RAM. But I see my RAM usage is not that high anyway (often something like 800 MB free) so maybe it is time to use x86_64 instead? I think it use DDR memory modules and max 2 modules so it is not easy to upgrade to more RAM. But there is no performance problems either, it runs very well on i686.

I upgraded my netbook (Asus EEE PC 1001HA) with an SSD disc and 2 GB RAM istead of 1 GB. But the intel Atom N270 CPU does only support 32-bit.. Arch runs very well on this netbook and I rather would not be forced to stop using Arch Linux on this one because of dropping 64-bit support...

nomorewindows · 2012-08-31 15:50:18

I happen to know that compiling or installing x86_64 packages on a i686 won't work, since the opcodes aren't present on the i686 for the x86_64.
Believe it or not I have a i686 server serving x86_64 and i686 clients, and I can't update the x86_64 packages without it giving me some trouble even when specifying arch to pacman. I have to use a connecting PXE or NFS client with the x86_64 processor to update the x86_64 packages on the i686 server.
I can't speak for why chakra has decided to move to x86_64 only packages/tool chain. FreeBSD also some years ago decided to phase out the aging i386 architecture in favor of the i686 and oncoming x86_64 architectures. But they also support various RISC processors. Arch has started to support ppc and arm architectures, and with parabolagnulinux, supports mips64el. So collectively, arch may someday support just as many architectures as debian.

Last edited by nomorewindows (2012-08-31 15:54:00)

Jristz · 2012-09-01 06:59:23

i686 is a pentiumpro right????
today I think is imposibble instal a proper arch in pentiumpro harware but in a pentium2 or 3 is factible
in plaze of drop i686 why no "upgrade" to a pentium3 (i786 ????) or pentium4 (i886 ????) this for one part can ramin a 32 bit compatibility is one need
for otrer part maintain compatibility whit asertain atom prosesro in market that not handle the complete full set of a 64bit (but can have the i786 set) and any crazy idea fomr intel or amd that drpo any x64 exclusive (at time) intruction for other...
prevent more complaining from the users and headached for mods
and finaly upgrade a lilttle the minimal perocessor need
not sure but probally this make Arch the firt in support only pentium3 (i786) and upers
and finaly maintain enought compatibility for lib32 and sertain software
probably tis innot the time for an upgrade but is the time for an update

Awebb · 2012-09-01 07:27:41

There is no i786 or i886. Counting like this ended with i686. From then on you'd think in steps like "i686 with SSE2" for example.

Jristz · 2012-09-01 07:38:05

Awebb wrote:

There is no i786 or i886. Counting like this ended with i686. From then on you'd think in steps like "i686 with SSE2" for example.

i say if fo give a name or you think is best cal (fallow my previous example) systemd-202-1-pentium3.pkg.tar.xz or simply i786.pak.tar.xz (again is an example)
and I read years ago (probably in 2005) that the denomination i786 was used internaly for intel in the develop of the sussesor of the i686

finaly pkgstats stats say for every 10 users 4 uses (or submit stats under) i686 you can read it

karol · 2012-09-01 11:02:55

@Jristz
It's a bit hard to read what you write, can you please use capital letters, punctuation and watch your spelling?

nomorewindows · 2012-09-01 17:28:56

Jristz wrote:

i686 is a pentiumpro right????
today I think is imposibble instal a proper arch in pentiumpro harware but in a pentium2 or 3 is factible
in plaze of drop i686 why no "upgrade" to a pentium3 (i786 ????) or pentium4 (i886 ????) this for one part can ramin a 32 bit compatibility is one need
for otrer part maintain compatibility whit asertain atom prosesro in market that not handle the complete full set of a 64bit (but can have the i786 set) and any crazy idea fomr intel or amd that drpo any x64 exclusive (at time) intruction for other...
prevent more complaining from the users and headached for mods
and finaly upgrade a lilttle the minimal perocessor need
not sure but probally this make Arch the firt in support only pentium3 (i786) and upers
and finaly maintain enought compatibility for lib32 and sertain software
probably tis innot the time for an upgrade but is the time for an update

I had one installation of a socket 8 pentium pro, and it worked just fine.

Jristz · 2012-09-02 02:49:17

@nomorewindows Work! ... ok, his is new for me

but, Thinking remove 64bit if 4/10 archer used i686 probably is a bad idea, specially thinking about the resents changes in boot prosses and the future bin -> usr/bin merge
firt finish this migration and after this think in "upgrade" the minimal processor needed

nomorewindows · 2012-09-02 04:21:29

Jristz wrote:

@nomorewindows Work! ... ok, his is new for me
but, Thinking remove 64bit if 4/10 archer used i686 probably is a bad idea, specially thinking about the resents changes in boot prosses and the future bin -> usr/bin merge
firt finish this migration and after this think in "upgrade" the minimal processor needed

usr and /usr/lib merge is a filesystem component, not a processor dependent component.
If you need more than 4GB of RAM, you have to migrate to using 64-bit. For most programs, adopting the 64-bit toolchain/memory model is all that is necessary.
Pentium MMX and up had 64-bit "quicky" processor instructions to help speed things up a little. They were after the Pentium Pro, but were not i686.

blackout23 · 2012-09-02 11:30:56

Skype is really no problem on x86_64. And there is nothing that could create confusion since the 32 bit libs are called lib32-libgl for example. Only additional 32 bit lib I needed after installing wine frome multilib was the pulseaudio 32 bit lib. After that everything was fine.

Last edited by blackout23 (2012-09-02 12:58:37)

ConnorBehan · 2012-09-02 20:10:43

I hope Arch drops i686 support by the year 2038.

nomorewindows · 2012-09-03 08:33:14

blackout23 wrote:

Skype is really no problem on x86_64. And there is nothing that could create confusion since the 32 bit libs are called lib32-libgl for example. Only additional 32 bit lib I needed after installing wine frome multilib was the pulseaudio 32 bit lib. After that everything was fine.

There was someone on the bbs complaining about the way that Skype itself was giving him some trouble, regardless of architecture.

Arch Linux

#26 2012-08-29 08:34:20

Re: Dropping i686 support

#27 2012-08-29 11:34:53

Re: Dropping i686 support

#28 2012-08-29 11:50:35

Re: Dropping i686 support

#29 2012-08-29 20:12:00

Re: Dropping i686 support

#30 2012-08-29 21:20:43

Re: Dropping i686 support

#31 2012-08-29 21:33:54

Re: Dropping i686 support

#32 2012-08-29 22:49:13

Re: Dropping i686 support

#33 2012-08-29 23:26:37

Re: Dropping i686 support

#34 2012-08-30 03:18:21

Re: Dropping i686 support

#35 2012-08-30 09:29:12

Re: Dropping i686 support

#36 2012-08-30 22:36:19

Re: Dropping i686 support

#37 2012-08-30 23:33:07

Re: Dropping i686 support

#38 2012-08-31 10:03:07

Re: Dropping i686 support

#39 2012-08-31 14:55:21

Re: Dropping i686 support

#40 2012-08-31 15:50:18

Re: Dropping i686 support

#41 2012-09-01 06:59:23

Re: Dropping i686 support

#42 2012-09-01 07:27:41

Re: Dropping i686 support

#43 2012-09-01 07:38:05

Re: Dropping i686 support

#44 2012-09-01 11:02:55

Re: Dropping i686 support

#45 2012-09-01 17:28:56

Re: Dropping i686 support

#46 2012-09-02 02:49:17

Re: Dropping i686 support

#47 2012-09-02 04:21:29

Re: Dropping i686 support

#48 2012-09-02 11:30:56

Re: Dropping i686 support

#49 2012-09-02 20:10:43

Re: Dropping i686 support

#50 2012-09-03 08:33:14

Re: Dropping i686 support

Board footer