Slackware64 & The Multilib Files. Should They Be Part of The Default Install.
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.
And.. If it DOES become an option in the installer, it should be one of those options that defaults to "OFF" or "NO" and/or be deliberately presented to the user for their choice. To clarify: even if a person opts for the FULL automatic Slackware install, they should still be asked if they want multilib or not, before proceeding.
And.. If it DOES become an option in the installer, it should be one of those options that defaults to "OFF" or "NO" and/or be deliberately presented to the user for their choice. To clarify: even if a person opts for the FULL automatic Slackware install, they should still be asked if they want multilib or not, before proceeding...
I think slackware-64 comes with mplayer and it works fine. You can also compile your own packages with slackbuilds for 64 bit that work fine.
Not if you need a codec for which there still isn't a 64 bit equivalent.
Originally Posted by forum1793
I agree with others that think the 64 bit should be pure and if added the multilib should be in extra.
If you need 32 bit, use the 32 bit distribution. What gain is there to run 64 bit with multilibs? Is there any performance gain? Does this address a memory issue whereby some 32 bit OS can't see 4GB?
It is going to be years before the thousands of 32 bit applications are converted, if ever, to 64 bit. Until that time why should it be necessary to run a 32 bit OS for some packages and a 64 bit OS for others?
Even mickeysoft has figured that out and the 64 bit version of windows 7 can run 32 bit applications out of the box.
Last edited by cwizardone; 01-26-2010 at 07:38 PM.
I agree with the spirit of a pure 64, but I'd hazard a guess that 35 to 50 percent of 64 users are also using the multilib packages.. There was a poll about slack13 variations and checking it the poll showed under 30 percent, but I know I for one , have installed multilib since voting and I'm sure a number of other users have as well.
So it seems to me that the question then becomes, "at what point does a common mod get included on the disk if not the stock install?"
I think /extra or an option in setup would be a good compromise, but I agree with GFG's thought that just going ahead with a "full" install should NOT install the multlib. Unless maybe there was a "full pure" "full multilib" option.
The part here about Pam is old I know but udev is moving to use polkit-1 pam etc . I do see that david will consider it. But its that thing of udev being released with out it patched and not caring if there is 1 or 2 linux platforms(unimportant, this is what it feels like) that don't want to use pam . 1) pam is to me linux taking the same stinking path that m$ took with office 97, IE, directx etc . 2) Pam should be a chioce to use it or use shadow or anything else that might come up. But not this forced crap. 3) it should be made as a package not a required by everything(this is where it fits into the path of IE, directx) etc . 4) Choosing not to use it shouldn't break things , hence the choice of them to STILL work with shadow.
So far the patch is working on my 64bit but xfce flux etc are not and need work a rounds too.
It still has created a mess as bad as pam is, GOOGLE has tons of info on problems with pam. Even looking for patches fixes for compiles over the years I have seen too darn many problems with pam.
I was thinking of emailing Pat to see if he was going to use it . But I see here he's considering it
I liked kde but am completely disappointed in it(I do know they decided because udev has forced them too).
The only thing that i will miss if KDE is dumped away from Slackware, is the K3B tool.
I'd be quite happy to see KDE dropped from Slackware. In my opinion KDE is better suited to the likes of Ubuntu and Mandriva. Fluxbox and XFCE fit the Slackware philosophy better. As you imply, K3b is a jewel in the crown of KDE, but once I found tkDVD to help me with command-line burning, I let go of K3b, and with it KDE, and this computer of mine is the better for it. Indeed, the only GUI program I *need* is Opera; I can't think of anything else I need that can't be done more efficiently and productively at the CLI. Give me the following programs and I'm a happy camper: Mutt, SLRN, elinks, wget, rsync, Postfix, getmail, Dovecot, tmux, urxvt, tex, cdrecord, growisofs, Vim, etc. All of them CLI; all of them unsurpassed in what they do; and all of them able to produce beautiful results. And it's beautiful results that matter; not beautiful interfaces which impede productivity.
Eric, do you have a link to the shadow/polkit patch?
I came here looking for information on installing PAM on my Slackware-current platform. I just tried building it with src2pkg, and got compile errors. So I decided to look for a prebuilt package instead. This was the first link from Google. I guess I need to redo the search with linux-pam.slackbuild instead.