> I haven't seen this behaviour in ages!  It is an
> nVidia issue, as they
> replace a system library (actually several of them) with
> nVidia-specific
> versions.  For some reason, those replaced libraries
> don't work 100% with
> the kinit system.  To prove this, fire up gdb and
> attach to the frozen
> process.  When you generate a backtrace, you will see
> nVidia binary blobs
> at the most recent call depth, even though kinit obviously
> does not
> compile/link against nVidia.

Ah, confirmation. :)

I don't know how to attach to the frozen process or generate a backtrace. Probably should learn. :)

I don't think I need to do any of that to confirm what I already see. I know that the proprietary Nvidia drivers replace a few files. The question is how do I/we work around that?

I have 3.5.10 running here as well as 3.5.13. I don't have this problem in 3.5.10 with the Nvidia drivers installed.

Asking people to temporarily restore the stock X libs or disable the Nvidia drivers will cause people to laugh and forget about testing or using TDE. That is not a doable solution for newbies who are interested in TDE.

1. Is there any damage in startkde of running kdetcompmgr as a background task?

2. What process started in startkde is launching kconf_update?

3. Why is kconf_update being launched?

4. Is there a way to prevent kconf_update from running?

Darrell