[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [Fwd: [Bug 53345] .bash_profile  script is not sourced]
From:       George <jirka () 5z ! com>
Date:       2004-02-27 19:50:26
Message-ID: 20040227195026.GA25320 () zinc ! 5z ! com
[Download RAW message or body]

On Fri, Feb 27, 2004 at 04:41:58PM +0100, Oswald Buddenhagen wrote:
> > So someone just needs to fork PAM, or at least start providing a
> > patchset outside of the official linux-pam.
> >
> it is absolutely unrealistic to expect a fork to receive any relevant
> amount of attention. that's because PAM is so critical and, well,
> "things work well enough". the only forks that have a chance are
> distribution-specific branches, but those usually don't see any new
> features.

Yes, but it's equally unrealistic to try to fix all of PAMs problems outside
of PAM and expect things to just work right.  This is a PAM issue and thus
ought to be addressed in PAM and not in the desktop managers.  Anything we do
there is a kludge no matter how pretty you make it out to be.  So we're just
then talking about workarounds for workarounds.  I think things work well
enough now that this just isn't top priority for me anyway.

For example I think there are many more broken things in the kernel then PAM
that are vastly more important to linux on the desktop.  Note that Joe User
will not ever ever care about how the dm startup happens.  Vast majority of
people will use the desktop as installed by the distributor in which case all
environment stuff is just set up in some distributor specific way and they'll
never touch it.  What is far more important now is that if I get a camera
that I can plug it in and pull pictures off of it.  Or any other piece of
hardware.  Or similar things on which free software currently sucks
donkeyballs.

I have had the unfortunate experience of trying to switch from redhat to
debian recently.  On debian, there are scripts for everything and many things
are done in a lot less kludgy and more automated way, and they work in almost
any setup that you can imagine.  So far so good.  All except that unless you
know how it all works it's VERY VERY VERY hard to do anything unless you have
lots of time.  RedHat on the other hand is far more kludgier, scriptier, and
oout-of-the-boxier (in terms of package setup) then debian, but also redhat
seemed a lot more just-workier.

That's why someone like Red Hat won't care about any improvements to the way
env is sourced in Xsession.  It makes no difference to the users anyway since
a very small (VERY small) percentage of users will know the difference.  This
is also why most likely no one there is interested in making PAM not suck.
And believe me, pam_env is the least of my worries about PAM.  PAM has far
worse and far more dangerous problems.

> there is another possibility ... let linux-pam die, absorb the
> interesting stuff from it into openpam, and let the freebsd guys do the
> hard work. :)

Obviously that's up to the freebsd guys :)  FreeBSD pam setup was having
goats with gdm's way of using pam though, so they're not out of the woods
either.  In any case, this wouldn't really be my top priority anyway, even if
I suddenly had a vision and god told me that my purpose in life was to hack
pam (which would pretty much be the only reason why I would ever do such a
thing, and that even though I'm agnostic, so I rate that possibility as very
unlikely)

> > startkde then sorts out the PATH situation accordingly.
> > 
> that's going to be the ugly part. let me see what i can come up with. i
> think it would be safe to derive the path from $0 even, so no
> startkde.in will be required. i'm wondering what to do about qt, though
> - anyway, that seems to have worked so far, so i won't bother.

I think people that install in weird locations usually have a tad more clue
about setting things up.  If they know how to run ./configure with a prefix
they know where to set the path IMO.

George

-- 
George <jirka@5z.com>
   Whenever you find that you are on the side of the majority,
   it is time to reform.
                       -- Mark Twain
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]