Tim Retout's www presence

Fri, 16 Jul 2010

Starting the Emacs daemon

The daemon feature of Emacs is great. But when should the daemon be started?

At one time I used an '@reboot' line in my crontab. But when you want to use things like Tramp mode (for editing files on remote servers transparently), you very quickly wish that emacs could talk to your ssh-agent.

So if you accept that you will be running a desktop environment (not always true), you can add the daemon to your equivalent of "System >> Preferences >> Startup Programs".

But then you find that Flymake (when used with cperl-mode) is not picking up any of your uninstalled, work-in-progress Perl modules. Wouldn't it be great if you could set $PERL5LIB to fix this? And doesn't M-x copyright require you to set "$ORGANIZATION"?

Ever since Debian bug #411639 was fixed at the end of 2007, we have the option of "~/.xsessionrc" for setting environment variables that will cover everything in your desktop session, including things launched from panels and startup scripts.

So now that's what I do. But I've yet to figure out a good equivalent for console-only systems. Maybe I don't need one?

Posted: 16 Jul 2010 23:48 | Tags: , , ,

Wed, 09 Apr 2008

GPG trustdb batch updates

A while ago, I mused on how network latency affects my email usage - one other cause of slowness in my mail client has been GPG key verification. Occasionally, when Evolution wants to check a signature, gpg takes 30 seconds or more to run, and the text of the message is not displayed until the end.

The reason gpg runs so slowly is that it sometimes checks its trust database to make sure it's up to date. However, it does not make sense to run this at the time you are trying to verify an email - it will just slow you down. Fortunately, this is very easy to fix - add 'no-auto-check-trustdb' to gnupg.conf, and set up a nightly cronjob to run 'gpg --batch --check-trustdb'. Ensure that you have 'anacron' installed if your system is not always on.

I have been trying a few methods for solving the network lag problems with email, but haven't reached a conclusion just yet.

Posted: 09 Apr 2008 00:00 | Tags: , , , ,

Sat, 22 Mar 2008

Encryption and disk access

Beginning last night, I reinstalled my laptop. Normally, if it were just to clean up some packages, I wouldn't do this - the aim was more to try out removing the disk encryption that I was using, and the effect has been quite dramatic.

I worked out a while ago that the device-mapper encryption was slowing down disk access - with it gone, boot times are much shorter (and I don't have to type in a LUKS passphrase). GNOME loads a lot faster. Additionally, bash starts a lot quicker than it did. I suspect loading the bash completion routines takes quite a bit of disk access. Update: No, I just didn't have the bash-completion package installed. Bash is still slow. GNOME is still faster, though... for now.

So, I will probably keep my new install. I need to investigate encrypting a USB device and integrating that nicely with GNOME and gpg.

Posted: 22 Mar 2008 00:00 | Tags: , , ,

Wed, 02 Jan 2008

Stale config files and upgrades

I've had two cases recently where an old configuration file has been causing problems, and there's no clean upgrade strategy.

My wireless card was made by Broadcom, and I use the newer b43 driver in Linux. However, the new mac80211 drivers introduce a second network interface (used internally by mac80211) but with the same MAC address as the normal interface. And because it gets created first, udev puts this master interface into the place where the real interface is meant to be, and the real one gets called 'wlan0_rename'.

The fix was to look at /etc/udev/rules.d/z25_persistent-net.rules on Debian, and either add 'ATTRS{type}="1"' to the appropriate line, or delete the file, and let it get created on the next boot.

Another time this has happened was with X.org. Jonny Lamb pointed out that removing the 'VertSync' line from xorg.conf fixed (or at least hid) my recent ati driver troubles. On running dpkg-reconfigure xserver-xorg, the new XRandR support lets Debian create a much smaller config file than it used to, which is cool. However, people upgrading don't get to take advantage of it.

Posted: 02 Jan 2008 00:00 | Tags: , ,

Mon, 31 Dec 2007

Fitts' law bugs

Firstly, a rant: as of December 2007, a self-righteous idiot named Chris Cunningham thinks he can change the name of "Fitts' law" to "Fitts's law" on wikipedia, in the name of grammar. To boot, he claims to have changed every link to "GNU/Linux" to point to "Linux", probably without regard to the difference in meaning. I am not happy. Fortunately, a recent attempt to become an admin was unsuccessful.

Anyway.

I noticed recently in Epiphany that I couldn't hit the scrollbar by slamming the mouse to the right edge of the screen. It turns out there are two bugs stopping me doing this, one less subtle than the other.

The less subtle one is that a recent commit to the ati driver turns on VGA output in my graphics card (even if there's no external monitor attached), and for obscure reasons this results in the virtual screen size being a little bit wider than 1024px. Fixes include "xrandr --output VGA-0 --off", or editing xorg.conf to disable that output monitor.

The more subtle one is actually a bug in Epiphany (or at least in GtkNotebook). With just one page open, using the rightmost pixel works fine; but as soon as you need tabs at the top, there's a two-pixel border stopping you.

Just another niggling desktop annoyance.

Posted: 31 Dec 2007 00:00 | Tags: , ,

Wed, 19 Dec 2007

Desktop annoyances - getting a prompt

Continuing my search for the subtle things that have annoyed me for years about my desktop usage, I want to think about shell startup times.

Application startup times have been done to death, I'm sure - it is one of the more obvious areas to work on when improving a desktop application. Evolution's startup time is still appalling, for instance; I count five seconds before I get a GUI, and many more before I see any email. Still, in the case of my bloated email client, it doesn't matter that much - I generally start it once a day, at 9am, when I need coffee anyway. It then proceeds to hang around in the background. It would certainly be nice for applications in general to start more quickly, but it's not the cause of these subconscious feelings of annoyance that I want to pin down.

Far more important than my email client are my terminal windows. One of the attractions of evilwm was that starting a terminal window was the focus of the entire window manager - the design is entirely motivated towards getting that window up as fast as possible, rather than aesthetics like window borders. However, these days I'm typically waiting for over a second to get a shell prompt. This is critical - when starting a terminal window, I'm usually about to perform a series of commands, and will really be paying attention to that lag.

There are two areas to consider: the time to start the terminal itself, and the time to start the shell inside the terminal. The shell startup time has been causing the biggest wait - bash itself starts very quickly, but turning on bash completion routines adds almost a second to the delay. Trying zsh out with completion enabled, it seems slightly better - maybe one-third of a second on a warm start. (Idea: add

PROMPT='%n@%m:%~$ '
autoload -U compinit
compinit

to ~/.zshrc and chsh away from bash. It's pretty similar.) This is the best argument for switching that I have seen so far.

The GNOME Terminal is relatively nice, and recent versions seem fast enough to start that changing terminal isn't going to make a significant difference. (Prove me wrong.) Some things about my desktop habits could be improved, though: I have a tiny icon on the panel to launch a terminal, and must be spending ages in mouse movements to start each instance. This is just lag in a different form. So, I've now deleted the icon and set a keyboard shortcut - GNOME has the option to set one, but none by default. Second, perhaps sometimes I should be using terminal tabs instead of opening more terminals - it depends on the task. I haven't thought of a cunning way to force myself to do that yet.

I'm now down to around a second to get an open shell prompt in GNOME without moving my hands from the keyboard, which is a lot better. I can still manage to start typing in the window before the shell appears, though, so I suspect some further work is needed on this.

Posted: 19 Dec 2007 00:00 | Tags: , , , ,

Mon, 17 Dec 2007

Desktop annoyances - network lag

Some things always feel uncomfortable about my desktop usage, even when I change solutions - KDE, GNOME, XFCE, all the way down to evilwm and beyond, to the console. I want to pin these problems down, in order to address them. First I want to focus on network lag.

Take email as an example. One of the biggest changes I made to my use of email a few years ago was to store all my email on an IMAP server, so that I can access it from any computer I happen to be using. This has obvious advantages - I have an archive going back years, can do spam filtering and classification in one place, and so on. It does mean performance can suffer, and I'm dependent on a net connection to read my old email. Compare how git changes how you can work with source code, both through its speed and through being able to commit while offline.

Once upon a time, when bandwidth was more limited, every computer had its own mail server, and all mail applications would read a user's mbox mail spool. That was a much better idea, and probably still is - with the exception that I want to take a copy rather than transfer all my email. After all, networks are now fast, and disk space is cheap. Thinking aloud, perhaps I want to run a local mail server on all my machines (so that everything can use a sendmail interface to send email), and then have a standard mail store which will be kept in sync with remote sites. (Bi-directionally, perhaps, for sent mail.)

With a single local mail cache, multiple applications will be able to take advantage of the one store. Individual client applications will be freed from the chore of checking IMAP servers for updates, which can be run automatically in the background by a single process when online. Planning ahead for multiple clients allows views of the mail store to be integrated anywhere in the desktop without requiring more than one mail cache (or lots of IMAP traffic). A similar centralising of network resources can be seen in Telepathy, although I haven't seen a centralized conversation logger.

The 'Online Desktop' idea is bigger than just the web, and it would be sensible to plan more standardized (cross-desktop) centralization of network caches for similar applications. I want to be able still to use my desktop while offline, and avoid perceived network lag while online.

Posted: 17 Dec 2007 00:00 | Tags: , , , , ,

Contact

Tim Retout tim@retout.co.uk
JabberID: tim@retout.co.uk

Comments

I'm afraid I have turned off comments for this blog, because of all the spam. Let's face it, I didn't read them anyway. Feel free to email me.

Me Elsewhere

Copyright © 2007-2014 Tim Retout