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 really do not see the reasoning behind providing multilib for Slackware64 as a release. Why bastardize Slackware64, not everyone will need 32-bit support for their system. If so then a user can always follow instructions.
Slackware is not a hold your hand distribution and thankfully never will be!
You as a user have the means to install or build a system as you wish with Slackware and that is because Slackware's design is solid.
The deal I struck with Pat when I created the 64-bit version of Slackware, was that Slackware64 would be pure 64-bit, and that I would be maintaining a multilib layer on top in my own repository, independent from Slackware.
This was a design decision by Pat, and there is no indication that this design will change in future.
The problem with things like multilib are that while it is a useful transitional aid, its mere existence tends to deter transition (the "people can always use the 32bit version so there's no need for us to make a native version" factor)
I don't want multilib on my system - in fact I'd sooner have the native 64bit stuff in /lib where it belongs rather than the /lib64 necessary to support multilib.
I believe that PV should seriously think about native multylib support on next Slackware64 releases. What's your opinion?
Nope, I am fine with my 64 bit systems. If you want multilib it nowadays is as simple as using slackpkg+ or phenixia's multilib/compat32 tools. In fact, other distros are steering away from being multilib by default, in newer Ubuntu and Debian versions you have to enable it explicitly.
I think if there was a time to ship multilib by default or even to devote resources to automation of adding it in, it was back in the 13.x days. Not including it made Slackware cleaner and in many was caused fewer problems with paths in build tools and the likes early on in the 64 bit transition, so over all it was the right call.
Back then there were projects that made assumptions about word sizes, address sizes, and alignments. It would have been helpful a few years ago but much less so now, almost all the open source stuff is cleaned up.
At this point 32-bit compatibility is needed for pretty much wine, and some browser plugins. I can't imagine there are all that many native binaries floating around anymore that don't also need ancient versions of libraries, making multilib alone a less than complete solution.
Eric has done fantastic work supporting multilib! At this stage in the game I find it easier to keep a stripped down 32-bit install runnable in a Linux Container (LXC) for those few items that have to stay i486. That way everything living in the container can just be static. Once its all working you leave it alone.
What are others using 32-bit for at this point? Other than the obvious wine, steam, skype?
Users who want multilib out of the box can also use mk-slack64-multilib to create their own slackware64/multilib DVD/ISO (here is a sample usage). This is particularly useful for users who want to install slackware64/multilib on more than one machine. Furthermore, mk-slack64-multilib automatically adds the following 3rd party tools into the serie AP : multilibpkg, compat32pkg and slackpkg+.
PrinceCruise, I was asking in the context of running Slackware64 and multilib; which implies you're on a x86_64 arch. I am interested in what has people still running 32bit software on an otherwise 64bit hardware/software platform.
Outside the obvious what is out there the typical Slackware user is running that:
Is only available as a 32bit binary?
Has source available but either does not compile or is broken on 64-bit?
Performs markedly better built for x86?
Has problems sharing data with x86 versions?
I ask this because its been a long time since I have really run across anything that can't go native x86_64; except WINE, and a couple previously mentioned binary releases. I am just curious is all.
I'm kinda on the fence with multilib, I have no problem setting up multilib myself, but perhaps at one point during the installation there should be an option to add multilib to the system, or maybe the best option is to have have a multilib in /extra.