I just solved one little snag, apart from which this is the smoothest desktop I have ever used, and so far it seems to be very stable. KDE 3.5.x sent me often mysterious messages when I shut down my computer (which was only cosmetic, and not *very* annoying, though), KDE4 goes down silently. And while KDE 3.5.x already was a very productive environment, KDE4 is incredibly intuitive. Many things are different, but I have no problems to navigate and find what I need.
And what is more: I have no hickups and don't miss anything from 32-bit world, at the moment. Especially multimedia applications run so well, now.

I bet, that Slackware64 will be released in less than six weeks. It's mature enough.

gargamel

Damn right! Excellent advice for any situation. Thanks, Franklin.


[Sorry to go off-topic]

For those of us unfamiliar with Slamd64, the 'c' series is what, 32bit compatibility packages?

Yeah, slamd64 added a new directory called 'c' for compatibility.

Yes

http://mirror1.slackadelic.com/slamd...t/slackware/c/

Well, I essentially use rpm2tgz to convert some RPM binaries, for instance for OpenOffice. It works well and it's much faster than compiling every new release.

As for my upgrade woes, I just probably didn't use the proper methodology : I upgraded the glibc, pkgtools then the kernel, rebooted to be able to run 64bits binaries but then I was in a deadlock as after the reboot, tools like ls and cut would not work anymore.
In the end, I created the DVD on another system, booted and installed everything. I then removed all the *i486|i586|i686* packages and things seems to work mostly fine now.

I'm currently rebuilting every 32-bits packages I made myself and should be full 64-bits tonight.

(emphasis mine)

You pulled the carpet out from under your dynamically linked binaries I think in this case, I would avoid "upgrading" glibc, because really what you want to do is to add in the 64-bit stuff first, then whip out the 32-bit stuff when you've put all of the fine china ... I mean ... 32-bit dynamically linked binaries away. I'm getting carried away with my analogies today.

Hi,
Your presentations for your argument(s) are not complete. An alternative would be to use a VM. I prefer VirtualBox. You could have your M$ or whatever running on that new Slackware64® -current installed host.

Please remember that this is 'Slackware64® -current' not Slamd64.

Sorry Fred no harm intended!

Exactly.
When I finally understood it, it was already too late. :-D

Hello.

I use Slamd64 to build both 64-bit and 32-bit applications (developed by me). I tested 32-bit build on 32-bit Ubuntu, it worked just fine.
So I would really appreciate to have a guide to run 32-bit apps under Slackware64, and to be able to build 32-bit apps under Slackware64 (So I would like it to be multilib in some way or another).

I want to note about WINE vs VM. VM is not WINE.
Running VM each time I need to run one little Windows application is wrong (I frequently run local GIS application in WINE to quickly look up a necessary address, just for a minute or so).
One disadvantage I can remember now for VM (VirtualBox only, because I didn't use other alternatives after I discovered VirtualBox for myself) over WINE is lack of full OpenGL support.
To ensure this you may run qtdemo.exe (shipped with Qt-4.5 SDK) in both WINE and VirtualBox and have a look at OpenGL samples.
The OpenGL sample in WINE-1.1.15 (built for Slackware) under Slamd64-12.2 (the app runs fine)
The same sample under VirtualBox-2.2.0 (the app doesn't work)

This thread will get you running wine http://www.linuxquestions.org/questi...442/page2.html. However please remember that Slackware64-current is a testing system and the packages that are added are from another similar testing OS.

samac

I signed up just to thank the Slackware team. Thank all of you for your hard work. I appreciate it. I haven't been this excited about a distro since Fedora Core 5 came out. I'm downloading the current iso build from the ftp.

Welcome Slacker Prime I hope you like it, remember to read all the docs and visit the forum with any problems you may have.

samac

The packages in Slamd64 are named differently. Each of the packages are named as $PKG32-$VERSION. This allows you to install them without interfering with the standard Slackware64 packages you will have installed. I am checking now as I write this, to make sure where they will actually be located on the system. It seems upon further examination, that the Slamd64 32-bit compat packages can be installed to replace your existing Slackware packages before any other steps are taken. Because the only thing that changes here, are the names of the packages. The filesystem locations are the same.

I have also reordered one of the steps for upgrading from a running Slackware system. I had previously written to install the Slackware64 glibc immediately after rebooting into the 64-bit kernel. That may lead to problems. I believe the kernel should still be installed and booted FIRST. However, because of the likely need for a 32-bit glibc even during the upgrade of the Slackware64 glibc, I am recommending now that the Slamd64 glibc32 be installed BEFORE the Slackware64 glibc is installed.

Other than that, the remaining steps should remain the same.

Shingoshi
>=(o_O)=>

I've just been advised by Fred Emmott (the Slamd64 creator), that there will likely be issues of incompatibility with the Slamd64 32-bit packages. That seems to increase the need for having packages built exclusively for Slackware64, and not depend on any other packages from other distributions.

Slackware64 will need it's own 32-bit compatibility layer.

Shingoshi
>=(o_O)=>