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.


Sasha

That would be a fair compromise, IMHO.

No. You don't use a compiling environment to install and run GoogleEarth or Adobe Reader because they can only be downloaded precompiled, the source code is not available.

You don't need the compiling environment to install wine on Slackware, either, if you just install a precompiled binary package.

32-bit runtime compatibility libraries would be enough to install and run all those 32-bit binaries. No 32-bit gcc, binutils, static libraries, *.so symlinks etc are needed.

I had to hunt down and install quite a few 32 bit library files to run the 32 bit version of MPlayer and it was necessary to install the 32 bit Xlib6 library files before Softmaker Office would run.

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.

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?

Not if you need a codec for which there still isn't a 64 bit equivalent.

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.

The only thing that i will miss if KDE is dumped away from Slackware, is the K3B tool.

Bump.

Another vote to keep 64-bit pure...no inclusion of multilib files.....my 2 centavos

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.

Excellent idea!

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).

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.

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.

Xavian-Anderson Macpherson
Shingoshi

0 members found this post helpful.

The question about the polkit-1/shadow patch has nothing to do with installing PAM on your system. Rather, the patch prevents the use of PAM.

If you still want that patch, it is included in the sources for my polkit-1 package.

Eric