About auto-forking the Slackware into Jurassic Linux for its beloved 90 old supporters and keeping going for rest of us...
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.
As it is, I'm using NIS/NFS for my central authentication needs, which works fine despite its shortcomings, and I'll see what the future brings.
You mean that in 2016 in your network all the data is transmitted in clear text, including password hashes, and there is no any host authentication. So virtually everybody can plug a laptop and get access to virtually everything. And that's the best Slackware can do.
You mean that in 2016 in your network all the data is transmitted in clear text, including password hashes, and there is no any host authentication. So virtually everybody can plug a laptop and get access to virtually everything. And that's the best Slackware can do.
Cheers
Kiki, I have a question for you: you really understand that a PAMified Slackware is literally incompatible as (binary) packages with Slackware and its associated SlackBuilds.org, who usually disable PAM?
That if you manage to obtain in your hands a PAMified Slackware Linux, it will be eventually Kikiware Linux, but no Slackware anymore?
You will have a standalone distribution, living and depending only in your additional packages.
Last edited by Darth Vader; 02-02-2016 at 12:06 PM.
As drawbacks are that is a relative complicated configuration and works only Linux-to-Linux. Or I haven't tried further, probably with UNIX Services for Windows, on a Windows Server, you can do that too.
Kiki, I have a question for you: you really understand that a PAMified Slackware is literally incompatible as (binary) packages with Slackware and its associated SlackBuilds.org, who usually disable PAM?
That if you manage to obtain in your hands a PAMified Slackware Linux, it will be eventually Kikiware Linux, but no Slackware anymore?
You will have a standalone distribution, living and depending only in your additional packages.
I think this is why Niki is using a non PAMified version of Slackware. He understands the work involved in maintaining a PAMified Slackware and chose to not go that route. That is why he requested it to be included in Slackware last year, which got quite the mixed responses, but since it was not added, he decided to live without it.
I wonder about something. There are Kiki Novak, Ivandi, Darth Vader and maybe others, all of them hitting into same issue: PAM.
How about, you guys, to create a League of Extraordinary Packagers and together to build-up your wanted Slackware with PAM. And it to be clearly different, making the mistakes improbable, to use RPMs instead of TXZs?
I wonder about something. There are Kiki Novak, Ivandi, Darth Vader and maybe others, all of them hitting into same issue: PAM.
How about, you guys, to create a League of Extraordinary Packagers and together to build-up your wanted Slackware with PAM. And it to be clearly different, making the mistakes improbable, to use RPMs instead of TXZs?
referring to some howtos that I found, some of them in French which I do not understand so I might be wrong, it seems at least partial something like this has happend in an simplified and easier way, which is using for example centos instead of Slackware, which is sad but in opposite what you suggest an applicable way to solve a problem.
I wonder about something. There are Kiki Novak, Ivandi, Darth Vader and maybe others, all of them hitting into same issue: PAM.
How about, you guys, to create a League of Extraordinary Packagers and together to build-up your wanted Slackware with PAM. And it to be clearly different, making the mistakes improbable, to use RPMs instead of TXZs?
And what advantage will offer that new RPM based distribution (I guess that you think about dependencies, then let's add to list yum or rpm-get), with PAM and Kerberos, shipping around 1000 packages and being compatible with nothing else?
Also, to maintain those 1000 packages, using Slackware as reference, is need exactly someone to work full time on it. Then, Kiki and Ivandi to come and to build on top their Enterprise Desktops.
At, conclusion, your idea is not the luckiest one.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
