Hmm. It would appear that you've posted this message in about 8 different threads that are related to Dropline. Not sure why you did that, but I guess you've gotten your point across.

It should be noted that Dropline GNOME for Slamd64 is not the same as Dropline GNOME for Slackware. The Slamd version is ported by a single, dedicated developer, and is still in a testing phase. In a way, it's an "unofficial" port of Dropline GNOME and will likely remain that way. It also has a different set of packages from what is included in the standard Dropline GNOME distribution.

Regardless, there is no logical reason why Cinelerra might not work in Dropline vs. your own custom GNOME install. It's hard to tell, now, without any actual information in regards to the crash bug.

I would suspect that there is a deeper problem that cannot be traced now. However, there is no reason that you shouldn't use the right software for you. If that is your own custom GNOME build, then it's probably a good choice.

This is actually not true. You do not need to rebuild anything else once your system has PAM capable logins. Software doesn't use PAM unless you explicitly tell it to. Old programs that don't use PAM do not magically gain PAM compatibility.

Speed is not the primary reason. Patches and functionality are the reasons. When you have a desktop that is wrapped around X11, it's important to have an X11 built that will perform correctly.

But seeing that there is a cadre of radical Slackware users that tend to call everything that we do into question...

In addition to the advantage of things like evdev support, we also have security patches that are (mysteriously) missing from Slackware's own X11 build. It's quite odd, actually, because Slackware has an updated version of ARTS that is patched for virtually the same issue...

http://lists.freedesktop.org/archive...ne/016146.html

Note that we are also the only GNOME desktop for Slackware that has more trivial things (like the GNOME font viewer) that is actually functional, due to a patch in Slackware's libxft due to a known (and fixed in later versions) and verified X11 bug.

The majority of the remaining items that you list here are components from ftp.gnome.org, and we feel that they are perfectly legit items to rebuild to have a 100% functional desktop. The exception would probably ony be Freetype (which is simply silly to build into X11 itself these days), Gnupg, and the Mozilla stuff. However, as I've noted before, Slackware's Firefox package is unsuitable for use as a backend for Epiphany and Yelp. This is why we have to build our own.

To us, it is more important to have a fully functional desktop, rather than give people the (false) perception of "non-intrusiveness"... That is indeed a popular word among the radicals, isn't it?

Sorry but this is true, you've just misinterpreted my words. I didn't said other software has to be rebuilt to make it working but it has to be rebuilt to Slackware becomes "PAM-aware" distribution. Samba, MySQL, ProFTPD, Openssh, UW-IMAP, POPA3D, NFS, Sendmail are a few examples.

I don't infirm lot of work behind a DLG has been done but it just can avoid disadvantages it like any external project has (from Slackware's point of view). Also I wouldn't name anyone who don't wish software from trusted source to be replaced as radical.

Good luck.

If I didn't understand, then it's possibly because this is not legible English. No offense. It just doesn't make any sense. Please be more specific.

I'm not seeing what the requirement is that you mention in the first post. There is no requirement to rebuild packages unless you actually *want* to make all of your software pam-aware. In that case, yes; it would need to be rebuilt. However, there isn't always a benefit in making all of your software pam-enabled. Most of them are fine just the way they are on Slackware for a typical configuration that doesn't require advanced authentication mechanisms.

You've just answered yourself in the 2nd paragraph.

DLG introduces PAM into Linux distribution designed and built without pam library and corresponding modules. It leaves mix of software some with and some without support of this authentication mechanism. Do you like this mix ? I don't.

I've never used it, but GNOME-Compat-2.10 has been updated recently, it's maintained by a regular of this forum, and it's designed for people who want the GNOME libraries without a GNOME desktop. I would recommend that the OP try it.

OK. This is completely different than what you were implying earlier, but that's fine. Perhaps you could have gotten to the root of the issue before, and specified that the *real* problem here is that you just don't like PAM - which is, of course, perfectly legitimate. However, I get the impression that you simply don't have a good grasp as to how PAM works, but that's neither here nor there, I suppose.

Your logic here is that it's faux pas to to install anything that wasn't originally included in Slackware. Seeing as there are *lots* of things that weren't designed and built into it, that presents a bit of a problem for those that want to use other software. So as far as you are concerned, people shouldn't install anything at all then? Correct?

My impression is that you're just talking for the sake of argument now, but I digress.

The funny thing about radicals and their issues with PAM is that none of them ever back up why "PAM is bad!" with any factual evidence. Most of them take the security standpoint (not that you have yet - I'm just saying it to put it out on the table so that we may block potential misdirections for this conversation), but fail to actually back it up with information as to why it's allegedly "insecure". To my recollection, in all of the time that Dropline has included PAM (for years now) there has yet to be a single relevant security advisory. The only things I've ever seen were external modules like pam_ldap that we don't even include and aren't even part of PAM itself.

Mixing pam-aware software and non-pam-aware software does not matter. The programs that you list above function *exactly the same* after they've been installed. If you can come up with some scenarios as to how there are some problems here, then I'd appreciate any insight that you could offer. Otherwise, I can only assume that your intent is to mislead and misinform.

I regret the turn of topics in this thread, however, I'm frankly growing weary of having to stand my ground every time someone decides to hijack threads with anti-dropline posts that are totally unrelated. If it's not one thing that can't be backed up, then it's off to "play the PAM card". Please folks... This is really getting old.

This would matter if doing so introduced some new method of authentication, but it doesn't because it didn't. It's being used as a shim to ensure that certain things happen to ease access problems when using the console. The software that doesn't use it, doesn't need to use it.

I hate to say it but either this happened well over two years ago, or you're just mistaken. Dropline does not have any KDE-centric packages at all. (That's squarely in "Pat-space".) It could not possibly have upgraded any of your KDE components.

(People should probably ignore this bit, as it's in response to a long-dead part of this thread.)

1. If you've installed swaret, you've basically turned over package management to someone else, so why would you care?

2. The last time I checked, swaret specifically avoided messing with any packages that match "*dl" because Dropline has it's own package update channel. (It's both not needed, and probably a good idea not to make changes to anything else's libraries unless you know what you're doing.)

(@#$!$ I just realized that this and the last response I wrote is a waste of time because georgejc decided to post his little warning in a thread that has been dead for over four months now.)

Keeping with stock Slackware packages leads directly to complications with keeping the system up-to-date, as I'll illustrate below. As Dropline very carefully maintains everything from the X layer "upwards" and avoids tampering with anything below that layer excepting in very special circumstances, no this is not likely to break dependencies or cause undue system instability.

The maintainer of Slackware has been known to set new standards for "resistant to change for any reason" (although he's still a fine guy). His "lack" of a recommendation appears to me to be partly based on the fact that it's got some design considerations that he wouldn't have gone with, and partly because it's not his job to go around certifying other people's work.

...and Dropline replaces the shadow package with... shadow. (OMG!) ...and let's clarify something--it's not "Slack developers", it's "Patrick Volkerding" who is one guy.

Another thing you're managing to omit is why Slackware doesn't use PAM. Patrick has been pretty clear about this in the distant past (because answering the same questions over and over gets old and is a waste of time. *ahem*). Slackware does not include PAM because he feels that for the majority of the single-user desktop machines and simple servers out there (which are the usual places you find Slackware) it's not needed. He also cites that PAM is a @#$%! to work with from a system architect's standpoint, and anyone who has used it would likely agree. So basically Patrick chose to leave it out because it's a big hassle for relatively little gain for the uses of Slackware that he is targeting.

Unfortunately that decision was something that happened a long, long time ago (in software-years) and is starting to show it's age. PAM, in the role that Dropline has put it in, solves a whole horde of issues that plague more modern desktops. (Luckily for the end-users, it's presence and functionality is entirely transparent.) Right from the start, PAM gives the system the ability to "know" whether or not the current user is physically present at the machine. This is very useful because it eliminates one of the #1 problems of a new Slackware installation, i.e., "Why does my sound not work?" where the cause is that the user has no permission to write to /dev/audio or /dev/dsp. Patrick suggests that users add their accounts to the audio group, which is fine, but it's work they no longer have to do. More to the point, when the user logs out their account will still have membership in the audio group if they go somewhere else and login remotely over ssh. Since they're not at the machine, there's not much point in this and represents a small security problem. The pam_console part of PAM makes sure that people are able to access the hardware that they're supposed to when they're at the console, and that they can't when they are somewhere else later on.

PAM also facilitates a mechanism by which the GUI system administration tools that so many people are fond of don't require being made suid to work (which is dangerous), and don't require that the user have to do any complex dance with sudo or su and/or setting X11 cookies in order to get them to work. Again, since pam_console is in play, applications can be easily wrappered so that when root privs are needed, a dialog box "just appears" asking for the root password. It also allows things like rebooting the machine to be done from the console without having to bother about a password, while not leaving it so that same user can reboot the machine remotely.

There are more things that PAM solves, but this post is already long enough and I'm nowhere near done.

I swear I'm not trying to be a jerk about this, but I've no idea what you mean by "important security intervention". I sincerely hope you're not trying to imply that the Dropline packages are in some way designed less securely than Slackware's. Xorg gets replaced (as has been said before) because Pat doesn't patch anything to fix bugs unless they cause trouble with other packages he's released.

...which is probably as it should be, because Freetype is maintained by different people than XFree was and has a different (and more rapid) release schedule. Since the X11 packages are being replaced anyway, this doesn't cause any problems and facilitates upgrading the 500K Freetype package without having to download another eighteen megabyte x11 package. Being that Xorg just got broken out into about two hundred packages so it's various pieces could be more easily upgraded, this seems to be a more correct route to take.

Pfft. Dropline's gnupg updates have actually gotten out the door faster than Slackware's. Dropline also started using the 1.4.x releases earlier to get at the automatic key-grabbing functions in it, which make Evolution's signed-mail validation a lot more useful.

For many of these, there are no updated Slackware versions of these packages, so unless you want to be running a two-year old Gnome release new versions must to be installed. When Volkerding stopped supporting GNOME, he stopped updating these packages entirely unless something else he was building required it, so most have fallen very, very out of date. For instance:

• glib - Slackware: 2.6.6. Dropline is currently at 2.10.3.
• gtk+2 - Slackware: 2.6.10. Dropline is currently at 2.8.19.
• gtkhtml - Slackware: 2.6.3. Dropline is currently at 3.10.2.
• librsvg - Slackware: 2.8.1. Dropline is currently at 2.14.4.
• libxml2 - Slackware: 2.6.22 (in patches/). Dropline is currently at 2.6.26.
• libxslt - Slackware: 1.1.15. Dropline is currently at 1.1.17.
• pango - Slackware: 1.8.2. Dropline is currently at 1.12.3.
• Firefox - Slackware: 1.5.0.1. Dropline is currently at 1.5.0.4, and Volkerding doesn't even compile Firefox himself.
• Thunderbird - Slackware: 1.0.7 (in patches/). Dropline is currently at 1.5.0.4. (I don't quite know what to make of this one)

These other builds will also replace all the packages you referred to, because they have to. By the way, Gware seems to have rolled to a stop back around March 14th with no GNOME 2.14 release in sight. Freerock has GNOME 2.14.1 in testing last I heard, but no formal 2.14.2 release. :/

I'd like to know why you decided to go on this FUD-fest. You, yourself stated that the question has already been answered. Very little of this had anything to do with the question at all. (I can't fault you for the age of the thread, since I screwed that up as well).

(Edited to un-bugger formatting of quoted text)

WOW Pam does all that! I thought it just made my vegetables taste better

Seriously tho,

If I put in gnome, thus PAM, and use KDE as my windowmanager, will I see any benefits to me in my KDE session as a result of PAM? Or is it only to my benefit if Iwere to run in gnome mode?

Thanks in advance.

It does happen frequently to you to reply to unspoken words and completely ignore what others say ? Somebody may find a demagogy in your answers.

• I never said other apps have to be rebuilt with pam support.
• I never said I don't like PAM.
• I never said it's "faux pas" to install anything except stock Slackware packages. (but replacing them it is)

I would attempt once again for you and evilDagmar point to problems I have with DLG:

• It replaces more Slackware packages then another builds like Freerock or Gware, so it is more intrusive then mentioned projects. The most serious examples are shadow and x11.
• I find inadequate and almost silly to argue for such serious changes(PAM introduction) with more pleasant work with GUI admin tools as the reason. Slackware already contains instruments how to run applications with changed UIDs - su and sudo. What's so wrong with gksu, gksudo, kdesu, ... frontends ? How frequently do you have to run graphical apps with uid 0 ? Not enough reasons IMHO.
• By installing DLG you have to rely not only on one source but two. When Slackware or DLG updates some package you have to either install it and hope it won't break anything from the opposite project (dependencies, already installed files) or avoid installation, but you may miss some important security fix. This is evidently an additional complication.
• It's reasoned to trust more to sources from 12 years old by time proven project like Slackware is then from relatively much more younger DLG. By installing DLG you'll have their suid versions of su, passwd, gpasswd, Xorg, xterm etc.

Finally no matter what you are using it's your choice. Personaly I could not care less if most of Slackers will use DLG.

Specifically you said for Slackware to become a PAM-aware distro that it would require recompiling many other packages, and you said so twice. Nowhere is it a stated goal of Dropline to make Slackware as a whole PAM-aware. Why do you keep bringing this back up and are you sure you know the meaning of the word 'demagogy'?

No, but you did the next best thing by reiterating "[...] adds PAM support intentionally rejected by Slack developers." More condeming than this is the following (color added for emphasis):

No, you didn't--those are zborgerd's words. The difference is meaningless, since you've repeatedly insisted that doing so is flat-out wrong. ...and you've been told several times now that this necessarily must be done, and the reasons why it's been done (to fix bugs that Volkerding will not fix, and to provide functionality that Slackware does not normally have).

If you're trying to argue that changes to Slackware that are done by anyone other than PV is completely out of the question, then you're effectively arguing that doing so is a sin because you're administrating systems based on religious dogma instead of the principles of science.

...and we'll try one more time to show you the flaws in what you're saying without merely copying and pasting our previous statements.

No, the only examples you have are shadow and X11, which both I and zborgerd have explained the purpose of. I have no idea why you would prefer that bugs and weaker security policies would remain in place. The other packages mentioned are also replaced by the projects you cited. (Hence my previous long and unwieldy post which you apparently did not read.)

How many steps would you like to go through to administer your system? Most people want to do as few as possible because they have actual things of merit to do. pam_console and console_helper facilitate making this happen by just entering the right password at the prompt. You don't have to remember to log back out either, since it's taken care of when the program exits. They also facilitate rebooting and shutting down your notebook without having to go the extra step of logging in as root. As to your IMHO, yes, that's right it's your opinion and at least we're able to cite something better than "Well I don't like it" for what we're saying.

Furthermore, that is not the only reason that was given by far, and I find the technique of only taking one reason given and acting as if it were the only reason and using a counter-argument along the lines of "all that work just for this one thing?" as patently offensive as any other appeal to ridicule tactic.

What "other" source are you talking about? Dropline makes very sure that things work against Slackware-10.2, continually caution people against using Slackware-current with Dropline because that's a "moving target" (although many do use it this way without problems), and does not tamper with other files on the system so the idea of it breaking Slackware is downright laughable. As to missing security fixes, unless someone goes and turns off part of the updater (which would make it their fault, not Dropline's) this is something that can't happen, at least with the Dropline packages. The updater is quite thorough about keeping a system up-to-date to the lastest teeny-release of GNOME and has an notification area applet to let the user know the moment it sees an update of any kind available.

I'd like to see some parity here. You're telling people they should use GWare and/or Freerock, and Dropline has been around much longer than both of those projects, and it's developers have been using (and building GNOME and other things from source) for a lot longer than that.

Not to disturb your worldview, but it's not like Dropline has entirely different and potentially insecure versions of the suid binaries you mention. They're the exact same programs Slackware ships, some with PAM support added, and the only changes are that some of them are built using newer and less buggy source releases of the software.

Then why do you continue with these flawed, dead-end arguments?

I can't comment on the rest of your post, evilDagmar, but the Slackware mirror you use must lag seriously. This is an extract from the the -stable changelog at www.slackware.org

as you can see 10.2 does include up to date versions of Firefox and Thunderbird.

PS: Calm down everyone <irony>Why can't we all just be friends?</irony>