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.
I not only find this very helpful and a great step for slackware but I also find it very amusing, especially with the secrecy. Thankyou Slackware Team.
I've never used -current before but I'm definitely going to start testing it out.
I know it would be a niche market. But I hope there will be a 32/64 bit cd/dvd type combo. I still have need of 32 bit and want to support 64 bit but think that 32 bit deserves just as much support. *yes i realize it's all going to the same place. However, it's how it looks on paper*
EDIT:
I have a 32 bit server. and my main computer is 64 bit.
If Slackware64 won't be multilib, can you still install Slackware on the same system?
Quote:
Originally Posted by lumak
I not only find this very helpful and a great step for slackware but I also find it very amusing, especially with the secrecy. Thankyou Slackware Team.
I've never used -current before but I'm definitely going to start testing it out.
I know it would be a niche market. But I hope there will be a 32/64 bit cd/dvd type combo. I still have need of 32 bit and want to support 64 bit but think that 32 bit deserves just as much support. *yes i realize it's all going to the same place. However, it's how it looks on paper*
This is something that needs to be answered. Being that Slackware64 has the directories of /lib64 and /usr/lib64, how much of Slackware's 32-bit libraries will have to be installed in /lib or /usr/lib to support 32-bit applications that simply can't be removed or upgraded? There seems to be little reason why both systems can't exist together on the same disk.
Edit:Some of these issues I've already dealt with firsthand. Having installed Slamd64 directly over an existing Slackware system, some of the issues were having two pkgconfig directories. One in /usr/lib/pkgconfig, and the other in /usr/lib64/pkgconfig. I don't think it should be a problem though, because you really don't want a system looking for 32-bit libraries in a 64-bit lib directory. The other thing to keep in mind, is that now that there's a Slackware64, there's nothing stopping any user from essentially building their own (glibc) multilib system, just as was done with Slamd64. Using Slamd64 as the guidepost, you could simply map out which libraries have to be rebuilt to support a multilib installation.
Now that there is a Slackware64, which uses /lib64 and /usr/lib64, I would like to have the ability to create /bin64 and /usr/bin64. I really don't think this is an issue, since the same $LIBSUFFIXDIR variable can be used for the directories of binaries as well. Simply adding the $LIBSUFFIXDIR to /bin or /usr/bin, would provide this without trouble. This is something easily implemented in any SlackBuild. Yes, this would essentially create yet another fork of Slackware64. Unless this feature found itself merged into it.
I think this is where having an existing Slamd64 installation will be of great help to me here. Using the find|file commands, you can easily search for binaries that are 64-bit and move them to either /bin64 or /usr/bin64. The only thing that would have to be done then, is to edit the accompanying pkgconfig for each package. Doing this would not interfere with an existing Slackware directory tree. And while I doubt that anyone else would be inclined to do this, it's something that I find particularly interesting.
That was intended to read as "We wanted to be sure we had everything working correctly before we released it to the public".
Slackware64(tm) was built from the ground up and required a *lot* of testing. Care was taken to give attribution where it was due and the usual Slackware(tm) standards were followed.
The non-official ports were thanked for their respective contributions and I know at least one of these maintainers is in no way offended by the announcement.
Quoting the actual text from the announcement.
I fail to see how you came to your interpretation.
It is very clear to me, that no offense was meant. I just think, it can be misread. The "greenfield approach" taken by the Slackware64 team means, that none of the unofficial efforts was good enough as a basis to start from. The last paragraph gives credit to the unofficial projects, but without the word "alternatives" it would read as: Thanks guys, but the stopgaps are dismissed now.
As I said, I am sure, this is not what Pat V. and his team were going to say. It still can be read that way.
EDIT: But, of course, the maintainers of unofficial ports must have reckoned with the appearance of an official release, any time.
Here it seems to be more clear that there was no slander intended. Rather, the comment is an unqualified statement of gratitude for the work of others.
Maybe you should have read that before running off at the mouth then, and especially before chiding someone else about a "misquote" of you.
Quote:
Albeit by the allowance of Slackware to take it's time to do things in a manner more consistent with the original philosophy. I can still see though how this might have been misread to mean something else. Because there still remains the implication that the Slackware philosophy is the only valid philosophy.
Does anything else really make sense? Of course "the Slackware philosophy" is the "only valid philosophy" for Slackware.
Quote:
But a larger question remains. If these other distributions were doing such a great job, why didn't Slackware proper (meaning the primary developers) accept their work to begin with, and simply provide guidance and build upon it. I'm guessing to some extent, philosophy motivated by ego is to account for this.
Projection perhaps?
Quote:
The very fact that Slackware64 is not multilib, suggests there would have been significant disagreement about it's implementation.
Perhaps it suggests that there was significant *agreement* about it *not* being multilib. Perhaps the multilib stuff comes later. Perhaps PAM will be added tomorrow. Perhaps you just don't know what you're talking about, but you combine speculation with hindsight and claim to have special insight into the future.
Quote:
That's sad. Because by not providing multilib by default to the Slackware community, a significant portion of that community is left out from a direct upgrade path.
The beauty of open source is that anyone who's more interested in seeing that happen as opposed to whining about its lack of happening is free to *make* it happen. The curse of open source is the sense of entitlement that leads so many to think that they should get to decide how others spend their time.
Quote:
It was because of Slamd64's implementation of multilib that I was able to install Slamd64 directly from a running Slackware system using slapt-get.
What makes you so sure that you can't do that with Slackware (32bit) to Slackware64? (Note that I'm not saying it's possible, but in theory, it should be).
EDIT: it's possible - I just did it. It's not exactly trivial to upgrade a live system that way, and I certainly don't recommend it, but it *is* possible.
Quote:
I would have liked a more complete solution from Slackware64. And without multilib, it's not complete.
It will *never* be complete for *every* individual, and any attempt to change that will make it worse.
JMHO, but you simply don't understand the issues involved with developing and maintaining an operating system, and your pretending otherwise just makes you seem like a fool to those who do.
Quote:
The immediate equalization of all knowledge among all beings.
Huh? No thanks - I don't care for the direction that would pull. And yes, *that* is ego.
Thank you Slackware team! Now I just need a 64-bit machine...
Quote:
Originally Posted by rworkman
The beauty of open source is that anyone who's more interested in seeing that happen as opposed to whining about its lack of happening is free to *make* it happen. The curse of open source is the sense of entitlement that leads so many to think that they should get to decide how others spend their time.
There are also some places that are hardcoded for slack32. e.g. the directories when making CD iso's. All you have to do is add a 64 to the end. Example:
Code:
Thanks. I didn't notice this as I was burning a DVD and it doesn't require to split it up, it just creates an image from the whole directory.
samac
The updated version of the mirror-slackware-current.sh script has an ARCH variable which determines which directory names are going to be used.
The default value for ARCH is 'x86' meaning it targets 32bit Slackware. If you change ARCH value to 'x86_64' then slackware64 is targeted.
You can change the value of ARCH in the script, or set it in your environment, or pass it as a commandline parameter to the script:
I not only find this very helpful and a great step for slackware but I also find it very amusing, especially with the secrecy. Thankyou Slackware Team.
Just out of curiosity, what was the reason for the secrecy? Simply to avoid the "Is it ready yet?" posts or was there more too it?
Just out of curiosity, what was the reason for the secrecy? Simply to avoid the "Is it ready yet?" posts or was there more too it?
I don't know what the intention was here. But in general, when a group of individuals maintain a condition of secrecy, it is typically motivated by a belief that power will be lost by the disclosure of information. The question then is, what power would or could there have been to be lost here?
The question then is, what power would or could there have been to be lost here?
Maybe the time, energy and nerves wasted on answering impatient questions, flood of useless bug reports and ill-founded criticism? Having a critical mind is good but aren't you being a bit enthusiastic about finding conspiracies in this issue?
I don't know what the intention was here. But in general, when a group of individuals maintain a condition of secrecy, it is typically motivated by a belief that power will be lost by the disclosure of information. The question then is, what power would or could there have been to be lost here?
Shingoshi
Didn't rworkman just answer that. They didn't want to put up with everyone and their grandmother telling them how it should be done so that they could focus on doing it their way.
I remember an interview from several years ago where Pat V. said that if he ever made a 64-bit port it would be "Pure 64". I think this mulitlib-ready style is a very nice compromise.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.