Well it seems like the glibc should be multilib capable. But no one has said so for certain. It seems that glibc would have to be multilib, in order for Slackware64 to be truly multilib-ready. I hope so! Simply having directories that will accommodate multilib, doesn't fully address it.

Shingoshi

Well there are 2 different sides being maintained so either pick 32bit or 64bit. If you need 32bit programs go with that.

I concur. Thanks for saying it better than I would have.

That's good enough for me. I like compiling my own software, although I primarily use slackbuild scripts from Slackbuilds.org or src2pkg.

There are a few packages I use that are actually just repackaged binaries (Open Office is one), but those are few.

Thanks. I look forward to playing with this and learning more as I go.

Regards,

-Drew

Seems, this has gone a bit emotional here...

My 2 cents.

1. Slackware has become my favourite distro over the years, because it is maintained so well. This has to do with the development philosophy the team adheres to.

2. The crew managed, never to let get philosophy in the way of the user, just for its own sake. The philosophy and vision on which the development of Slackware is based, provides useful guidance. But in the end, Slackware is not (only) developed for its own development team. In my experience, the crew carefully listens to users. The members I had direct contact with, listened and provided great support, sometimes within minutes (!!!). (THANKS so many times!)
Remember the announcement that the JDK was going to be dropped. I am so grateful that the decision was rectified, based on user feedback, as Slackware is the best Java development platform, I know.

3. If (and only if) the community demands it, there will be a comfortable solution for 32-bit support in Slackware64, I am sure. Time will tell.

4. On the other hand, it's not really an answer to install two systems, when they have demand for 64 and 32-bit applications. It is a matter of cost and comfort to be able to run as many applications in one environment. And unfortunately some of us have to run proprietary closed-source 32-bit stuff. Having to install a 32-bit system only to run a couple of programs is not really appealing. But running only a 32-bit system on 64-bit hardware seems not to be the answer, however, to me.

But in the past the Slackware team has always found the best answers to such dilemmas. I am confident, if there really is a problem, we'll see a solution for it, very soon.

gargamel

This was the only thing that I was attempting to say. When I've listened to the number of users who don't run the newest hardware, and or are jealous of someone who does, it's obvious that cost is a major concern for many users.

Even if it's not a matter of financial cost, it's a matter of the consumption of time. I have multiple systems, connected together by network. And I know that sometimes it simply isn't so easy to manage running software on two separate systems, even if you can (I do it because I enjoy it). Then there's the issue of time management. It would simply be an imperfect condition to be in. This computer is my communications server. I run Slackware on it. It is however a 64-bit processor machine (with 8GBs of memory). Which is why the aforementioned issue with running a 64-bit kernel. I wasn't running a 64-bit kernel for my amusement.

I've been quite loyal to Slackware, regardless of what others have wanted to interpret from my writings. I specifically haven't installed Slamd64 on this machine, thinking (by intuition) that a 64-bit implementation of Slackware was not far off. It was in fact because I saw (ARCH=x86_64) changes in SlackBuilds, that I correctly surmised that something was happening behind the scenes. And it's not like I don't have experience with 64-bit systems. I still want however for there to be a fully implemented 64-bit Slackware. Yeah. I have been annoying the hell out of many people. Sorry. But I tend to think of the cost involved in anything I intend to do. When it came down to a choice between Slamd64 and Bluewhite64, I chose Slamd64. Not because one was better than the other, but because of comprehensive cost.

I have built packages for a very long time. There's no lack of experience here. But I don't think it's adequate to assume that everyone who runs Slackware, is or should be expected to build the foundation of what they need to use their system on a daily basis. I'm sure there are many users who have never built a single package. Many of them likely only use Slackware for simple tasks that are fulfilled by the base installation. I have no problem with building packages I know Slackware would never release in binary form. Ironically, I've been criticized in the past for how many and the type of packages I have built.

I guess by using another analogy, it's a matter of either having a complete toolset, or having to create your own wrenches. I'd simply rather not see Slackware throw a wrench into the gears of it's own progress.

Shingoshi
>=(o_O)=>

If anyone was wondering why Slackware64 was kept under wraps for so long, this thread certainly answers THAT question. The only thing I'm still wondering is how much all this hot air contributed to global warming.



All kidding aside, nice work again by the Slackware and SBo teams. It's nice to see folks improving my Distro AND sticking to the philosophy. Makes me feel good about my choice of operating system. I don't use a machine that would benefit from Slackware64, but as a user of many SBo slackbuilds, it's nice to see this project feeding Slackware so many new features.

Thanks!

My machine DOES benefit from 64 bits. In fact, it runs as if it had only waited for this. And KDE4 is a dream!
This is the first time, I am on a --current system, and KDE4 alone is worth it!

So YES and THANKS to Pat V., Eric, Robby and everyone else who has contributed to this!

gargamel

ok excuse my ignorance here, this has probably been answered already. I realize from reading that Slackware64 will support the use of 32bit libraries and programs via the /lib and /usr/lib directory because all the 64bit stuff goes into /lib64 and /usr/lib64 just like slamd64? However unlike slamd64 slackware64 will ship with /lib and /usr/lib more or less empty which means if you want to run 32bit apps like say skype or doom3 or whatever you will be responsible for filling the lib directories with all the required dependencies?

I think the first step for anyone wanting upgrade to Slackware64, is to FIRST install the 64-bit kernel. If for any reason the rest of the installation fails, you will still be able to boot your system. However, if you still have a 32-bit kernel installed and try to install the Slackware64 glibc, you will have lost your system. This wouldn't be permanent though. You would simply have to use an installation disk to correct the problem. So here's what I think should be a safe course of action:

Wait until the release of Slackware64-13.0!!
Keep in mind, this is the only way to be able to run any 32-bit applications.
1.) Download and have ready the packages from Slackware64/a
2.) Download and have ready all of the packages in Slamd64/c
3.) Install the 64-bit kernel, along with the kernel modules.
4.) Reboot your system into the 64-bit kernel.
5.) Install the 64-bit glibc.
6.a) If you're still able to run your system, finish the update of other packages.
7.) Now install the Slamd64/c packages.
6.b) If you wind up stopped at step #5, reboot your system. After reboot, the new glibc should be in use.
8.) Install and test any other packages.
9.) If you're unable to run the new glibc on the 64-bit kernel, you'll need to use an installation disk.

If you encounter the condition at step #9, do this:
1.) Boot your system using the installation disk.
2.) Mount your root partition, and any other partitions required for installation.
3.) Chroot into your root partition, and "cd /anywhere/you/have/your/packages.
3.a) Alternatively, you may run setup, select your root partition and bypass the disk format of course.
4.) Upgrade existing system packages.

Shingoshi

Here's something I think every user who installs a 32-bit compatibility layer should keep in mind.

The use of Slamd64 libraries for running 32-bit applications, WILL NOT BE SUPPORTED!!

I'd like to hear anyone say something other than that. If taking the same earlier mantra, that Slackware wasn't 64-bit, we'd have to extend that line of reasoning, and say Slamd64 isn't Slackware64. Now maybe things will change. But given the historical rancor over the installation of UNOFFICIAL (Gnome, Slacky.eu, Vislab, etc) packages, I really don't see how that attitude is about to change any time soon. This means that any user who chooses this 32-bit course of action, is (likely) automatically UNSUPPORTED!!

Shingoshi

Shingoshi your hint about using the slamd64/c packages worked. I am now running quicken under wine and I would like to thank you for that.

samac

I am one of the few people running Slackware that has ever upgraded a running system to Slamd64. So I had real experience in going about this. Nothing was imaginary here. The only concern I had, was whether it would be just as easy with Slackware64. I'm glad you reported that it was. Congratulations!!

Shingoshi
>=(o_O)=>

WTF is this supposed to mean exactly? What support am I going to lose? Will I suddenly lose the ability to ask intelligent questions?