Here are some shots of the NUT web interface.

This is my list of interesting-looking packages in Debian that i haven't had a chance to look at yet:

• songwrite - guitar tab editor & player
• lilypond - music typsetting
• vlc - media client
• jack-rack - sound processing
• luma - GUI for accessing and managing LDAP database
• blender - 3D studio
• inkscape - vector drawing
• ldap-account-manager - webfrontend for managing Unix and Samba accounts in an LDAP directory
• rosegarden4
• muse - Qt-based midi/audio sequencer
• dlint - Checks DNS zone...
  

After more than a week of testing combinations, i've managed to install Debian etch (amd64 version) on my new Core 2 Duo system.  It required using the latest daily build and putting my IDE CD-ROM into my USB IDE enclosure - it appears that the the problem is that Debian kernels haven't got a pata_marvell module yet.  Interestingly, OpenSUSE 10.2 installs perfectly.  More details can be found at Debian bug report #397062.

I've found this article at fatofthelan.com to be an excellent resource when setting up my email system.  Postfix has an excellent track record for security, Clam AV seems a perfectly adequate substitute to commercial virus scanners, Spam Assassin picks up most spam with a bit of tuning, and amavisd-new is a flexible way to plug them all together.

(22:01:19) blahdeblah: Q for cvs-buildpackage users: what is the correct/recommended way to build a native package (i.e. where the upstream version source is in the same CVS tree)?
(22:05:11) blahdeblah: I've experimented with debian/ being tagged with debian_version_X_Y_Z-A and the remaining source being tagged as upstream_version_X_Y_Z. This results in a non-buildable package when exported by cvs-buildpackage, whereas if i just cvs export all the files, it works fine. Do i need to set up rules more like an upstream package than a native package?
(22:08:43) blahdeblah: Is everyone scared away by the mention of cvs-buildpackage, or am i just too verbose?