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.
Things would be a lot easier if Slackware64 were multilib out of the box instead of just multilib ready.
As far as I remember, when I came to this forum, there was a big scandal around Multilib in the forum, mainly caused by a small number of Debian refugees, who insisted that this Multilib be integrated into Slackware.
From what I understand, the choice to be Slackware x86_64 as the non-Multilib architecture is a fundamental design decision of the operating system, which Mr. Volkerding did. And that Slackware64 will forever remain non-Multilib.
If you think you know better than Mr. Volkerding, you are my guest to create your own Linux distribution. Why are you wasting your genius using Slackware and challenging the fundamental decisions made by Mr. Volkerding?
Last edited by ZhaoLin1457; 04-30-2024 at 02:30 AM.
As far as I remember, when I came to this forum, there was a big scandal around Multilib in the forum, mainly caused by a small number of Debian refugees, who insisted that this Multilib be integrated into Slackware.
From what I understand, the choice to be Slackware x86_64 as the non-Multilib architecture is a fundamental design decision of the operating system, which Mr. Volkerding did. And that Slackware64 will forever remain non-Multilib.
If you think you know better than Mr. Volkerding, you are my guest to create your own Linux distribution. Why are you wasting your genius using Slackware and challenging the fundamental decisions made by Mr. Volkerding?
Agree with you Slackware64 should remain non-Multilib forever!
Anyway, it's too much work to support so many versions, including the 32-bit ones.
I'd like to see an added command line option to upgradepkg that would make it ignore multilib compilers and libraries.
This would over complicate upgradepkg with the basic purpose of upgrading packages not filtering out 3rd party packages. This is what slackpkg with blacklist does. Better yet use slackpkg with the slackpkg+ plugin without the hassle of using blacklist.
If you think you know better than Mr. Volkerding, you are my guest to create your own Linux distribution.
I don't make any such claims, but I do note that there once was a distribution called Slamd64. This was back in the Slackware 11-12 era when Slackware was a 32 bit distribution only. Slamd64 was a Slackware clone compiled for x86_64. Good old Slamd64 was multilib out of the box. Once the official Slackware distribution started to provide Slackware64 there was no longer much need for Slamd64, but I do miss the official multilib support.
I also realize that the need to run 32 bit programs on a 64 bit distribution might be less today. But still, sometimes it is convenient to be able to run old 32 bit programs.
Slackware for the x86_64 architecture (or Slackware64 for short) is a pure
64-bit Operating System, but by design it is "multilib-ready".
If I remember correctly Eric persuaded Pat to do just enough work to make Slackware multilib-ready, despite not actually being multilib. I forget the details of what that actually means, as obviously there are multilib versions of glibc and gcc that replace the Slackware packages.
More there are packages in Slackware less Pat can have time to work on Slackware Framework.
-undervolt and compiz can may be get out of Slackware GIT.
-Libcacaca-0.99.beta seems to make Marav laugh a lot so I can't ask for remove it.
-Unless Pat is a fan of Clint Eastwood, can be removed the good the bad an the ugly (I'm on a multimedia slackware and since 2021 without gstreamer all is well)
For Slackbuild it's the same, I would not want to see Slackbuild doing a competition for the number of packages with Debian.
Adding exotic packages could come in confused the user who is looking for the most relevant package.
This would force the maintainers to do quantity instead of quality.
Why am I jealous of users of new versions of Slackware?
they have a Kernel Slackbuild and much more.
they have Slackbuild.org with sources.(I have a bad memory of the hacking of palemoon source)
Modern Slackbuilds are much cute than this 14.2.
* I'm not sure I have the skills to keep a multilib Slackware.
alien multilib is no less official than Slamd64 was.
Yes, this is true, Slamd64 was an unofficial x86_64 port of Slackware. But with Slamd64 there was a single source of security updates which worked out of the box without breaking anything. Today, official Slackware64 security updates might break your alien multilib installation.
Today, official Slackware64 security updates might break your alien multilib installation.
I think this is an additional and important reason to use Slackware64 exactly as thought by Mr. Volkerding. Without Multilib.
I personally think that Multilib is a whim, not a necessity. I have never used Multilib. What is it good for?
Mr. Volkerding, how about building the x86_64 kernels with CONFIG_IA32_EMULATION=n ? It seems that in big houses this is considered an important security measure.
Last edited by ZhaoLin1457; 05-01-2024 at 06:24 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.