SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is a little bit too much ... fundamental design of that operating system .... little bit way too much :-)
we are not talking about changing /lib64 to /lib or something fundamental that was an actual design decision, just some binaries different compiled and or additional available
Essentially, we talk here about the support for a "single architecture" vs. the support for "multiple architectures"
My friend, I know you as being a fine programmer (and I appreciate much your work), so permit me to not believe that you aren't aware that the discussed subject is one of the very basis and fundaments for an operating system.
Last edited by Darth Vader; 07-03-2018 at 09:08 AM.
I agree, there will be for some time, software that requires 32bit support.
<snip>
BUT, if we talk about the idea to dump the Slackware 32-bit in a partition where's already installed the Slackware x86_64, that I believe that's a pretty bad idea.
Hmm, see zero references to dumping Slackware 32-bit on a Slackware64 install. Multilib does not fit in that category, not even close. The beauty of Slackware (32-bit) apposed to Slackware64, is Slackware can be installed on 64-bit hardware. Not a lot of "new" 32-bit machines out there.
Quote:
How nobody is perfect and everyone do mistakes, there I will agree with @Drakeo, that Eric Hameleers better to put the plug soon to his huge mistake named Multi-Lib, where he go against to very operating system design chosen by Patrick Volkerding.
Not that I care if this blasphemy is alive or not, but he misguide the Slackware users. As seen right on this very thread.
WOW! What an incredibly terrible (or hilarious) thing to say. Multilib may be a mistake to you but to me it is an addition that allows me to run 32-bit programs on my Slackware64 system. I say that multilib is a perfect addition to Slackware64 and in no way goes against the Slackware64 (pure) design of Patrick Volkerding. I am willing to bet many here agree with that. I for one am very happy that Eric made this possible. I do not want to run Slackware (32-bit) on a 64-bit machine. Multilib gives me the the ability to run run 32-bit software, without a full blown 32/64 system or installing Slackware (32-bit). I have five compat32 packages installed that are not part of multilib. Eventually I may reduce the compat32 packages down to only those I need, right now I am satisfied with the current state of multilib.
Quote:
Because Slackware64 is a pure 64-bit system, then we should accept it as it is. Beyond the pure 64-bit Slackware is no Slackware anymore. That's AlienWare.
Oh please... speaking for my self... I do accept Slackware64 for what it is. On two of my systems I pollute it with multilib, BY CHOICE. It's still Slackware. By this logic, how dare I pollute Slackware with non-slack 3rd party programs.
Quote:
I use Slackware 32-bit (and I am rather devoted to) and I use Slackware64 as our BDFL seen proper to ship it: pure 64-bit. BUT I never felt the need to mix them, and I never felt that the x86_64 variant is "incomplete". Rather, both architectures ships the same software. Literally.
I use Slackware and Slackware64 as shipped, aside from putting non-slack packages on it. I also mix it up. Still Slackware.
Quote:
There are other ways to run a 32-bit distribution from a 64-bit one: LXC containers, for example.
Yes, my method is VirtualBox (Windows 7 and Slackware-14.2) I can also have clean and separate infrastructures and power up as needed. I am writting this post from my desktop Slackware64 with multilib, ktown (testing) that runs Windows 7, Slackware-current, Slackware-14.2 and eCS powered up as needed.
I agree, the humans tend to be egoistic beasts, who see only their own interests and habits. Mine included - I am of the same species, after all.
I am in the same boat
As the maintainer of a distribution based on Slackware, I'd egoistically prefer not have to integrate such a major change. Actually I just won't provide new 32-bit versions.
Although the first computer I used professionally had an Intel 8080 (8-bit) and 64 K RAM (the maximum allowed with a 16-bit address bus) inside. Maybe it's still possible to find such a beast in a museum
Essentially, we talk here about the support for a "single architecture" vs. the support for "multiple architectures"
My friend, I know you as being a fine programmer (and I appreciate much your work), so permit me to not believe that you aren't aware that the discussed subject is one of the very basis and fundaments for an operating system.
Beside the fact that I am talking about simple practical solutions, I admire they way you defend Slackware to keep it as it is explaining us why a change is not that easy possible (except of course when it touches topics you are interested in ;-)
You are an original, good that this forum has you!
Beside the fact that I am talking about simple practical solutions, ...
I believe that Patrick Volkerding chosen the pure 64-bit architecture because he intends the Slackware users slowly to migrate fully to 64-bit and in a long term, him to abandon the 32-bit at all.
That forever growing software base will have a price sooner or later, because certainly his work time is quantifiable and limited.
That's why also I believe that he will never accept to transform the Slackware64 in a Multi-Lib solution; and Eric Hameleers already stated that his Multi-Lib project will be put down when the Slackware 32-bit will cease to exists.
The Eric's Multi-Lib may look convenient in a short sight for some people, BUT is not what I believe that Patrick Volkerding intends for a long term.
In the far future I see the Slackware as being pure x86_64 only, with no 32-bit support at all.
Do not be surprised if in the Slackware 16 development cycle (or 17, or even 18, who know...), you will observe that there is no 32-bit ChangeLog anymore and also no Multi-Lib repository in the Eric's servers.
Last edited by Darth Vader; 07-03-2018 at 11:21 AM.
I believe that Patrick Volkerding chosen the pure 64-bit architecture because he intends the Slackware users slowly to migrate fully to 64-bit and in a long term, him to abandon the 32-bit at all.
That forever growing software base will have a price sooner or later, because certainly his work time is quantifiable and limited.
That's why also I believe that he will never accept to transform the Slackware64 in a Multi-Lib solution; and Eric Hameleers already stated that his Multi-Lib project will be put down when the Slackware 32-bit will cease to exists.
The Eric's Multi-Lib may look convenient in a short sight for some people, BUT is not what I believe that Patrick Volkerding intends for a long term.
In the far future I see the Slackware as being pure x86_64 only, with no 32-bit support at all.
Do not be surprised if in the Slackware 16 development cycle (or 17, or even 18, who know...), you will observe that there is no 32-bit ChangeLog anymore and also no Multi-Lib repository in the Eric's servers.
I do not expect to get 32 bit in Slackware, and this is sad, however, mistakes are made to be fixed. It takes just longer for some than for others ;-)
I have deep respect for Erics work, but it is on the mirrors that he might turn off if he loses interests, or that might get out of sync with the Slackware version of packages if he is for any reason not available. Having such an esential package on a 3rd party repo is an architectural miss design, IMHO, of course, everyone can see that different.
32 bit will not extinct so fast, if you want speed, and do not need more than 4GB ram for a program, 32 bit is it (but the -m32 version, not the converted one)
... and Eric Hameleers already stated that his Multi-Lib project will be put down when the Slackware 32-bit will cease to exists.
I hope it will be in a far future, because I still need multilib for my steam games I've bought :-/.
BTW 32bit compilation support (-m32) in slackware64 would be nice, because without multilib it takes about 3 hours to recompile the toolchain on my machine.
I hope it will be in a far future, because I still need multilib for my steam games I've bought :-/.
Eric's Multi-Lib relies on Slackware 32-bit packages and if there will be no Slackware 32-bit anymore, also he said clear that he will NOT further maintain a 32-bit distribution compatible with Slackware, IF Patrick Volkerding will pull the plug for 32-bit architecture.
So, if you want Slackware 32-bit to live, better for you to stop playing as "a 64-bit user" while you strongly depend on the 32-bit variant, and to buy Slackware 32-bit subscriptions and DVDs.
This is the single way to "persuade" Patrick Volkerding to continue to support the 32-bit architecture.
IF he sees the sales of the 32-bit release as being insignificant compared with the 64-bit variant, probably he will lose the interest for, sooner or later.
Quote:
Originally Posted by pc2005
BTW 32bit compilation support (-m32) in slackware64 would be nice, because without multilib it takes about 3 hours to recompile the toolchain on my machine.
Why you do not just stay into Slackware 32-bit if you need it soo much? Or, to use it in a dual boot with x86_64? You people make your very future with your very hands.
About the Multi-Lib is clear, it is not a feature offered by Slackware64, and this was a choice intentionally made long time ago, even before the first release of it.
Last edited by Darth Vader; 07-03-2018 at 01:09 PM.
I do not expect to get 32 bit in Slackware, and this is sad, however, mistakes are made to be fixed. It takes just longer for some than for others ;-)
I have deep respect for Erics work, but it is on the mirrors that he might turn off if he loses interests, or that might get out of sync with the Slackware version of packages if he is for any reason not available. Having such an esential package on a 3rd party repo is an architectural miss design, IMHO, of course, everyone can see that different.
32 bit will not extinct so fast, if you want speed, and do not need more than 4GB ram for a program, 32 bit is it (but the -m32 version, not the converted one)
How the heck happens that, in my entirely 20 years of daily usage of Slackware, I never used or needed to use that "esential package" ?
Last edited by Darth Vader; 07-03-2018 at 01:11 PM.
How the heck happens that, in my entirely 20 years of daily Slackware usage, I never used or needed to use that "esential package" ?
just because "you" do not have any use case for it does not mean it is not essential, but your argument discloses of course a lot and is the final truth, for "you" of course. I am to tired for discuss this further with you, you handling this topic on a level I can definitely not follow
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
