[Users] Need help, moving from kmail-1.13.5 to claws-mail
Steve Litt
slitt at troubleshooters.com
Mon Feb 24 17:17:16 CET 2014
On Mon, 24 Feb 2014 09:49:23 -0500
Gene Heskett <gheskett at wdtv.com> wrote:
> On Monday 24 February 2014 09:34:03 Ricardo Mones did opine:
>
> > On Mon, Feb 24, 2014 at 08:44:51AM -0500, Gene Heskett wrote:
> > > On Monday 24 February 2014 08:42:10 Paul did opine:
> > > > On Sat, 22 Feb 2014 22:05:35 -0500
> > > >
> > > > Gene Heskett <gheskett at wdtv.com> wrote:
> > > > > /var/spool/mail/$user
> > > >
> > > > Create a 'Local' account in Claws and that will pick up mail
> > > > from /var/spool/mail/$user
> > > >
> > > > with regards
> > > >
> > > > Paul
> > >
> > > This is what I am doing in kmail now. But in the long run, I'd
> > > like to put dovecot in the chain so I can access it, using claws
> > > in imap mode, from any machine on my local net.
> >
> > If you have X servers on your local net machines you can simply
> > ssh -X your server and run Claws Mail there but viewing it locally.
> >
> > regards,
>
> Ok, but if I leave this copy running 24/7 like I do kmail, can this
> machine actually run another non-interacting copy when I ssh -Y
> coyote from say, lathe.coyote.den and run the 2nd copy beside the one
> that is already running? Previously I have not had a lot of luck
> trying to do that. My background script that uses inotifywait for
> that, will cause reboot to fix system problems if the dbus cache
> pipeline fills up with unreplied msgs.
Leave dbus alone. Don't use it in your script, and Claws won't use it
either. Kmail makes dbus go 99% of CPU, often so often that I had to
use a cron job to look for and kill dbus instances remaining above 94%
for more than 5 seconds.
I'm a huge fan of encapsulation, and dbus, even though not made by the
Klowns Destroying Everything (KDE), is a huge encapsulation violation.
If I absolutely need two processes to talk to each other, I can usually
find ways of doing that myself, especially if I'm the guy who coded one
or both of them.
Thanks,
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
More information about the Users
mailing list