Using mutt on Linux to transfer your old mbox mail folders onto GMail

Unlike many webmail providers, Google don’t allow you to upload your folders from your old mail system in mbox format and import them. This is a pretty basic feature if you ask me, they really should.

There are a number of alternative ways. GMail does support fetching from other mail servers via POP3 (but not IMAP, another strange omission), so if your mail is all in your inbox at the old place that might work, but mine is organised into several folders, and I want to keep that organisation damnit!

Needless to say, someone has written a nice piece of software to do the job; in this case Mark Lyon’s GML. I was about to give this a whirl, but while I was waiting for the requisite Python lib to install, I found a much simpler way… click to read on…

Continue reading Using mutt on Linux to transfer your old mbox mail folders onto GMail

Terminal features wishlist: #1: Paste Intercept

A terminal program should have sufficient intelligence to recognise that, when (a) it is at a shell prompt, and (b) the user has just middle-clicked and sent hundreds of lines from the copy-paste buffer hurtling towards the shell prompt, the user may have made a mistake, the user’s mouse inadvertantly striking some object perhaps… and it should ask him whether he really wants to do that.

This was part of a much larger post which got killed by a bug in WordPress… “Are you sure you want to edit this post?” it asked. Yes, quoth I. And it was gone. 2 hours of scribbles, vanished, and even going back in the browser doesn’t recover it.

Related wishlist item: Anyone know of a little program that can sit on the desktop, probably always on top (so SMALL) and on all desks, which will show the current contents of the (Unix) copy-paste buffer, and provide a button to clear it? Even better if it can save a few of them too, even just 2 or 3. I like the Unix system. Left click and drag to select. Left click and right click to select by marking start and end points. Middle click to paste. It’s simple, it’s fast, it avoids faffing with menus. But there’s always a slight frisson of doubt which sets in as time passes between cut and paste. Currently the only way to find out is to paste somewhere. I’d like to just be able to look at the corner of the screen, see a tiny rendering of the contents, and know.

M-Audio Xponent + Linux + mixxx

Updated: 2007/07/27 – New section on LEDs. Update on mixxx SVN.

In case any of you who have read my review of the M-Audio Xponent are thinking of getting one and wondering “but will it work under Linux?”, the short answer is a resounding Yes!… except for the LEDs, so far. More on that later.

I use Debian unstable with a hand-rolled kernel. YMMV, of course, but the chances are that if you’re using any modern distro you’ll be fine. In fact you may not even have to manually insert the kernel modules if you have a working udev setup, you might just be able to plug’n’play.

Full details below the cut, as they say…

Continue reading M-Audio Xponent + Linux + mixxx

M-Audio Xponent review

M-Audio Xponent

Update: After you’ve read this article, before you rush out and buy one of these, you should read this update (don’t worry, I’ll link to it at the bottom of the page too.

It’s rare for me to suffer from “gear lust” but the M-Audio Xponent set my pulse racing when I discovered it on the web. I’ve now had it for a few days so here’s my review. I won’t be reviewing the Torq software: I haven’t used it, as I only have Linux at the moment.
There’s a separate article about my experience getting the Xponent working with Linux and mixxx.

Review follows:
Continue reading M-Audio Xponent review

import_request_variables(): When will PHP stop being insecure by design?

Re Bugtraq post PHP import_request_variables() arbitrary variable overwrite.

This sort of thing really brings it home how the PHP core team still
don’t seem to really understand security… or would rather sacrifice it
in the name of backwards, very backwards, compatibility.

If you’re going to provide a function like import_request_variables()
to replace the blatantly-unsafe register_globals, how on earth can you
get it so badly wrong that it’s even more unsafe?? I mean, security 101
for a function like this would be:

  1. Don’t overwrite any existing global variables (come on!)
  2. Failing to specify a prefix should be at least an E_WARNING.
  3. Stop pandering to people who wrote or still use bad code originating back in PHP3 days, and aim towards getting rid of the whole concept of registering global variable symbols from user-supplied data. It was always a bad idea, it’s never going to stop being a bad idea, just drop it.

I also get terribly bored of seeing bugtraq reports of a “full path disclosure” bug in some app (like it’s a big deal too), only to find that it is, once again, PHP itself that’s at fault. Sure, the sysadmin on a production machine should set display_errors = Off, but if it’s left on why does PHP show the full path? If the purpose is to help the programmer developing code (who somehow doesn’t have access to the server errorlog), then the programmer doesn’t need the full path, they already know where the docroot is — so when showing errors from scripts in the docroot, why not only show the path relative to the docroot? And if from an included or required file outside the docroot, just the last directory component ought to suffice. The full path can still go in the error log, and then maybe developers would learn to use it instead of relying on errors going to screen…

PHP can be secure, but it really needs to stop offering features that are insecure by definition.