Perhaps, but 64-bit distros also require more RAM. Hence the choice of 32-bits for RAM-constrained environments.

32-bit software is also being slowly phased out, hence why it's not officially supported by Slackware in Slackware 64. The 32-bit version of Slackware is available to users, but it's not recommended for people with 64-bit compliant systems.

Face the facts, 32-bit software is dying and is only in maintenance mode. All CPUs, PCs, and systems sold and built nowadays are pure 64-bit systems.

At best, adding multilib only creates a basic level backwards compatibility layer for software that hasn't been patched for 64-bit compiling. That list of software is getting extremely short as days go by. Slackware really doesn't need multilib at all to function. At best, I've hand-counted about 10 or less SlackBuild projects that require 32-bit compilation, the biggest of which is WINE, though, honestly, WINE (Wine64) can be built for 64-bit support only eliminating the need for 32-bit.

I think its because of the keep it simple, stupid principle, not because 32 bit will be obsolete one day.

Regards.

Think Alien Bob deserves our thanks more than he's getting. If it wasn't for him we wouldn't have Slackware 64. It's even better that he's given us instructions on making our installs multilib (not to mention the scripts and what not).

If you want native Slackware, change all ="$SLKCFLAGS" to ="$CFLAGS" in the slackbuilds (x11 and maybe a couple other packages have this setting elsewhere) in slackware source directory and run the slackbuild scripts. You can make this easy by making small scripts to automate this. If you're new at scripting it's not that hard since you only need to insert your commands into a text file.

It's true though that dozens of slackbuilds need a patch or tweak to build successfully (dev86 comes to mind) from not being updated. You should also copy each slackbuild to a slackbuild.somethingelse file, and only edit the copy so you can update your source tree easily with wget without wasting traffic and/or overwriting your edited slackbuilds. You can add each patch needed for a slackbuild into a script to keep track in case of updates.

Multilib would work the same except you need to have -m32 in your CFLAGS environment variable, before building (make sure it's exported before building), and make a second copy of the slackbuild to slackbuild.somethingelse.m32 or whatever; each second slackbuild copy would also need LIBDIRSUFFIX="64" changed to LIBDIRSUFFIX="" (you might have to change ARCH=(uname -m) to ARCH=i486 too but we need Alien Bob's answer).

You need gcc, binutils and glibc, multilib packages before building anything 32-bit or multilib (you need to change SLKCFLAGS in Alien Bob's gcc and glibc slackbuilds with your own settings for native slackware; and add -m32 where appropriate); and you probably need stock multilib packages before building any native multilib packages.

Find it crazy how stable Slackware is with so many different ways people use it. Installing the packages you want from the DVD, building your own native Slackware, or going multilib never seems to fail.

Nah, don't think that's why. Keep it pure, that's what I think. I also think, as Holering just alluded too above, we have Slackware64 through the efforts of Alien Bob. Many thanks Eric! And thanks for multilib too. Of course many thanks to Pat too, for without none of this would be possible.

I do agree however, that 32-bit is on the way out, especially today.

Multilib will be around for a long time on x86, maybe forever. The Steam platform is 32 bit and will be in the foreseeable future, just as most commercial binaries. I don't see any "transition" happening.

The main issue is pretending x86-64 is a new "platform", which it isn't, it's just a another operation mode for a x86 CPU. Every commercially successfull implementation of a x86-64 operating system therefore is multilib. IA32 is going to die together with x86-64, if that ever happens (if and when the whole world switches over to ARM).

Running a "pure" x86-64 system sounds great in theory, but it has not much practical value in my opinion.

My choice would be a single hybrid 32/64 bit distribution which runs both modes of x86 CPUs by kernel choice. So its either a 32 bit system with some useless 64 bit files lying around or a 64 bit multilib system on a capable CPU. Later on first option would be dropped, but not the multilib one.

Yes, that would take disk space, but in 2013 this is not really an issue anymore.

Not for many years to come. As we speak 32bit ms-windows is still being installed on new computers.

Last time I worked for a somewhat larger OEM here in Germany the ratio of 32 to 64 bit installs was about 1:15 (one 32 bit installation for about 15 64 bit installations), so 32 bit is clearly on the decline, at least on x86 architecture.

Yes, most PCs and Laptops anymore now have the 64-bit OSes pre-installed. The only 32-bit systems I've seen as of recent on the market are 32-bit ARM architecture units, not x86 based units.

And furthermore, the 64-bit versions of Windows are all multilib. They all include the "WOW64" subsystem for running 32-bit binaries.

(Incidentally, it took me forever to learn that the "WOW64" I kept seeing in Wine's release notes didn't refer to World of Warcraft support).

Windows on Windows has been around for a long time now. You might have seen or been exposed to WOW16 back in Windows NT, 95, 98, ME, 2000, and XP when you installed an ASPI driver. It wasn't used much as most of those systems had varied support of 16-bit DOS and Windows 3.1 applications anyway, but it existed.

Well, that "benchmark" says apache is 16 times faster in 64-bit than in 32-bit on the same hardware. Do you still trust the Ubuntu folks?

Neither in ruario's post nor the comment from Hans Peter Anvin he linked to is anywhere mentioned Ubuntu or a benchmark. Posted in the wrong thread, maybe?

Search for the thread title of hpa's.

Nonetheless the comment from Hans Peter Anvin has nothing to do at all with Ubuntu or benchmarks, it explains the technical reasons why 64 bit reduces overhead on systems with enough RAM that they need to use HIGHMEM when running 32 bit.