SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
Do you use RPMs much then? I'm just curious, as I've never really found a need for them, personally.
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.
I upgraded the glibc, pkgtools then the kernel, rebooted
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.
Slackware64 will not run 32-bit applications. Wine or anything else for that matter.
You will have to either load Slamd64 compatibility libraries, or build them yourself. Which would you like to do?
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.
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 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.
If this has already been answered, all the better...
Originally Posted by H_TeXMeX_H
So I have a question, what's the difference between installing the slamd64 compatibility libs and just using the slackware libs in slackware64 ? I heard that slamd64 used many of the slackware packages to make the compatibility libs ... so what exactly is the difference if anyone knows.
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.
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.