'Pure 64-bit' does not mean that there is no /lib64 and /usr/lib64. If we pay any attention to LSB/FSHS standards, then the only 64bit arch which rightly uses lib and /usr/lib is the Itanium -and thios is only because of historical precedent.
x86_64 systems should use /lib64 and /usr/lib64 while 32-bit systems (or multilib system components) should use /lib and /usr/lib. There is no case for having /bin64 and /usr/bin64 directories -the path to the binaries does not need to be segregated. But the LD_LIBRARY_PATH does need to be segregated so that whenever a binary is executed the right libraries can be found for it.

A multi-lib system should also have both /usr/lib/pkgconfig and /usr/lib64/pkgconfig. pkgconfig files are architecture-dependent -even though they are only text files. They are arch-dependent because they tell where the linkable libraries are found. If you build an application to run as a 32-bit program, then the libraries it links to should be looked for under /lib and /usr/lib. For 64-bit, then /lib64 and /usr/lib64. To properly do this, the proper pkgconfig flags must be used at compile-time, just as the proper -m?? flags have to be passed to the compiler and configuration routines.

It has been stated that Slackware64 is '32-bit ready' -to me that means that the facility for using additional 32-bit libraries, for those programs that require them, has been included in the current setup. This means that it does not limit you to being a 64-bit-only system. IOW, the possibilty is there.

It boils down to this:
All software that is available as source will be able to run on 64bit - you just compile it. Programs like madwifi, OpenOffice, VLC, MPlayer are easy to compile on slackware64 (although OOo will require a beefy computer and will take forever to compile) for instance.

Software which is distributed in binary-only format - usually this is proprietary software - will only run on Slackware64 if the software producer makes a 64bit binary available. Think of the NVIDIA binary driver for X.Org, Adobe's flashplayer for Firefox, Sun's Java Runtime etcetera. Luckily all of the above are available for the x86_64 platform now, which was exactly the reason we at Slackware thought the time was finally right for a 64bit release.

Programs like WINE are used in the Linux world to be able to keep using programs that were written for the MS Windows OS. These programs are usually 32bit, which requires you to have a 32bit WINE executable. This 32bit WINE will not run on Slackware64 and therefore you will not be able to run Windows programs that way.

Having said that, there are several Virtual Machine programs such as QEMU, VMware and VirtualBox which are available or can be compiled on x86_64. You can still run Windows in a virtual machine and use a RDP or VNC server inside that Windows VM to access your Windows programs seamlessly on your Slackware64 desktop. Modern 64bit capable PC's are often equipped with hardware virtualization support which makes running a Virtual Machine very easy without slowing down the host computer.

Of course, if you rely on others to compile and package your software for you then you will have to wait until packages appear that have been compiled for x86_64. But a real slacker does not wait for slapt-get repositories to catch up and compiles the software himself. SlackBuild scripts obtained from http://slackbuilds.org , Robby's or my own repository make this task pretty straight-forward.

Summarizing: if you are an open source enthousiast then Slackware64 will run all your software - and faster too! If you use Windows software a lot, or use proprietary Linux software that is not available in 64bit binary form, then Slackware64-current is not for you at this moment in time.

And to all who are reading in the announcement what they want to see... the first line of the official announcement states: Do not try to skin the cat too early. Some in this thread are trying to kill Slackware64 before it is even released as final. Applause, good show! If you do not like slackware64 then do not use it, it's quite simple. It's not as if you do not have an alternative.

Eric

I think the initial suggestion was that Slackware64 would not provide multiple library installations, hence multilib. It just seems contradictory. The emphasis on "Pure 64" seems vacuous at best. But none of this discussion will matter to anyone who tries installing 32-bit applications on Slackware64, only to find out they don't work. And I think you actually have to have multilib enabled in glibc for it to work. If Slackware64 ships without a multilib glibc, users will be faced with having to rebuild their toolchain. That's not something many will be looking forward to. Especially not after having found themselves in a situation with many applications that simply don't work. That will be a lot of wasted man-hours. That would be like getting married, only to give your new wife a b00b-job.

Shingoshi

Those who upgrade without reading the UPGRADE and HINTS files screw their systems anyway, nothing special about 64 bit here...

Eric,

I dips me lid in humble appreciation.
Thanks to you and the Slackware crew for the fantastic surprise and all the hard work behind it.
Picking holes in a leap forward is easy, making it happen is certainly beyond me.

I'm simply saying that if anyone assumes there will be a seamless upgrade path to Slackware64, they will find themselves seamless! As in having ripped-out all the stitches in their crotch!

Shingoshi

I think everyone heard you the first 100 times.

Of course that would only apply to those who had recently undergone transgender surgery.

You're such a spiteful little man. What point are you trying to bring across? In this thread you are the only one who are making the assumptions. I've seen your fights in the Vector forums, managing to piss off the Vector creators for exactly the same reasons: you are trying to force a Linux distribution into doing things it was not intended for... and then accuse the creators that they create junk. You invariably run into compatibility problems which are caused by your own incompetence.

Remember the 64bit kernel you found in another distro and which you installed in Slackware (32bit), then accusing Slackware of expressly being crippled because gcc would not allow you to compile 64bit software? It is a perfect example of who you really are. I hate to tell you, but the world does not revolve around you.

Eric

Only because Slackware64 doesn't (??) currently employ a multilib glibc system. I regularly ran Wine on Slamd64. And I'm not advocating for users to dismiss Slackware64. I'm simply saying 32-bit users are currently dismissed by Slackware64.

Shingoshi

Yes but if they did things right they wouldn't have assumed that in the first place. Besides, Slackware 64 shouldn't be obliged to provide a seamless upgrade path. If it can that's fine, but it's more important to get the new 64-bit system work up to the standards and philosophy of Slackware than to make it backwards compatible with the 32-bit version.

WTF? You seem to forget that Slackware is now available in two flavours: 32bit and 64bit. If you are a user with a need for 32bit programs then by all means install Slackware. This is and will be an actively developed Linux. If you have a need for 64bit software then install slackware64.

On the other hand, Slamd64 as well as Bluewhite are 64bit distros which have to offer 32bit compatibility because they are limited; they do not ship a separate 32bit version.

Eric

I actually asked a lot of questions on #slamd64 before trying to run that 64-bit kernel. I was assured that it would work. For the most part, it ran as expected to. It was only after installing it that I found myself unable to build kernel modules. And as it was later explained to me, the compilation of a 64-bit kernel and it's modules, doesn't require a 64-bit glibc. It was only because the flag for x86_64 was not set in gcc that kept it from compiling the kernel and it's modules. Without that, you can't run gcc -m64.

And I have since had it explained to me that glibc has to have --disable-multilib, in order for multilib not to work. Now if that's not right, please let me know. Because I remember looking at the SlackBuilds for glibc, both from Slamd64 and Slackware. And Slamd64 doesn't disable it. So is the multilib disabled (as above) in Slackware64?

Shingoshi

While I have no experience with BlueWhite I did run 64 bit K/Ubuntu for
over a year and running 32 bit applications was completely transparent to the user. No hoops to jump through.

This one was good! Great return!

And I've been laughing too hard to be spiteful.
Shingoshi