Switching away from mutt
After having used mutt for about a decade, I decided it's time I move away from it, for various reasons that I won't go into here.
I've been evaluating thunderbird^Wicedove now for a few weeks, but I can already see I won't keep using it forever, because I find too many issues with it:
- I can't tell the thing that I never ever ever want to write HTML-formatted emails. While there is an option "Compose messages in HTML format" in the "Account settings" dialog, that only seems to impact the behaviour of the client upon "new mail", not its reply behaviour, forcing me to go to Options->Format and switch it off.
- To make matters worse, the HTML editor and the plain-text editor are not the same dialog. That means it is not possible to switch on HTML formatting if it wasn't on originally (not a problem for me, but I can imagine it being a problem for others), but also that the fugly quoting style (vertical line next to the text) of the HTML editor is not removed when you switch from HTML to plain-text. Further on, it has issues when you want to remove white space, where it will remove entire quoting levels rather than just an empty line. This is horrible, horrible behaviour.
- While there is support for multiple email addresses connected to the same IMAP account, it does appear that there is no support for automatically choosing the right email address based on user-defined rules, such as "which mail folder are we currently in". Having to remember that I need to select the right mail address is tiresome and error-prone; e.g., when I'm in a Debian-related mail folder, I want my mail client to use my Debian mail address automatically. It appears the only way in which icedove can automatically select sender addresses is by checking the recipient list in the To: and Cc: headers for any of its configured mail addresses, and using that to decide what to put in the from: header.
Any one of the above would eventually be enough for me to grow tired of icedove and switch to something else; but the three combined mean that I'll be looking for something else fairly soon.
Suggestions are, of course, welcome.
Service announcement: Planet Grep moved to a different server
The old server was having hardware issues, so we've moved the set-up to a different machine. The DNS has been updated, so you should be reading this from the new location already.
Now while I don't expect any problems, I can't exclude them yet; so if you do find something odd happening, do not hesitate to tell me.
Email address is at the top.
Dear HP,
I bought a ScanJet N6350 a few years back, in the belief that it would work. After all, you write free Linux drivers for all your printers, and when those printers are multifunctional printers with scanners, you do make sure the scanner bits of those printers work too. So it shouldn't be too hard to write a Linux driver for that scanner too, right?
Apparently it is. For some reason that I can't imagine, you decided that my money is worth more than my stress levels.
- The HP ScanJet N6350 is a combination USB/network scanner. That's great; I don't need it to be right next to my laptop all the time. Having the ability to get it sent to me by email (as your product page claims it can do) reduces my workload. Unfortunately, what you didn't mention on the product page is that the scanner is pretty dumb; it does network, yes, but the only way in which it can send emails is by using some application running on a system on the other end of the network connection. That's pretty silly. It wouldn't be so bad, however, except...
- ... the system on the other end of the network connection has to be running Windows. That's right, you didn't write a Linux driver for some reason. You also didn't publish the network protocol, and even the USB connection seems undocumented. So I can't use Linux to scan my documents. It wouldn't be so bad, however, since I already have a Windows XP virtual machine lying around somewhere, mainly because there's this satellite navigation system builtin to my car that also requires it; I just installed your scanners oftware on that machine, and I can scan. Except...
- ... whenever an error occurs in the scanning process, the UI locks up completely. I can't retry the last page that I was trying to scan, and often I can't even save the document anymore, either; I have to rescan the whole document. That wouldn't be so bad, except...
- ... the ADF is total crap. If I put more than a few pages on the feeder, and they've got some horizontal folds in them (as is likely with snail mail that came out of an envelope), I'm very likely to end up with a paper jam, or with multiple pages sucked into the feeder at once, causing an error and a loss of my scanned document. That wouldn't be so bad, except...
- ... the process for finishing one scan and starting the next involves stopping and starting your whole scanning software, which takes a rather long time. As such, I'd prefer to just scan a whole stack of incoming snail mail in one go, and then use pdfsam to split up the PDF file. But then I have to babysit the scanning process so that I don't get any errors; but I fail at that about as often as I succeed, meaning, it usually takes a long time to get through the stack.
Dear HP, you suck. I fail to understand how the basic loss of functionality after a failed scan managed to get through your testing. I fail to understand why you think Linux users should be able to print, but not scan. And I especially fail to understand why I should waste my time with such an expensive device that can't even perform its basic functionality with more than 10% success rate.
The devops "installer"
puppet and similar things are very nice tools for managing your systems. Rather than doing the same thing 100 times, it's much more interesting to spend some time describing how to do something, and then have it done hundreds of times automatically.
However, I'm starting to see a distressing trend lately. I'd like to say that puppet is not an installer, nor is it a replacement for one. Here's why:
- By giving me a script that calls puppet to install your software from the interwebz, you're making it very hard for me to install your software in case I'm running behind a paranoid firewall that I don't have access to.
- By giving me a script that calls puppet to install your software, and sets up things so it will try to run puppet agent against your server (presumably to keep my installation up-to-date), you're making it much more difficult for me to manage that system as part of my larger network, which is already being managed with puppet.
Please, pretty please, with sugar on top: just provide packages. If that can't be done, just provide clear installation instructions and/or a puppet module that I can include or something. Don't assume I'm a system administrator not worth his paycheck.
Thanks.
note: the gitorious example above is just that, an example. I've seen more cases of people doing similar things, not just gitorious. Surprisingly, it's mostly from people who're on the ruby kool-aid. I hope that's not related...
Update: (2013-04-18) despite my usage of buzzwords in the title of this post, I did not mean to imply that any of the above has anything to do with devops. Instead, what the post is supposed to say is that you should not fall into the trap of believing that devops methods, which may work wonderfully internal to your organization, will therefore also work wonderfully for processes outside your organization.
Dear supplier,
I don't usually blog about work, but this time around, you maxed it.
When I specifically ask you to not ship goods, I have good reasons for that. Specifically:
- I'm not at my office all the time. Yes, I'm often there, but I'm also often at a customer's place (you know, so I can actually make money). When I'm not at a customer, I tend to be at the office in a noon-through-evening schedule, rather than a morning-through-late-afternoon one (I hate getting out of bed if I don't have to). Since we don't have any employees, this likely means your logistics partner will find a closed door with nobody answering the bell.
- The result of that is that we'll often find that your shipments end up at your logistics partner's warehouse. Since I have to drive to a warehouse anyway, I might as well choose to drive to the warehouse that is closest—yours.
- For this "service" of shipping goods away from interesting locations, you charge €20+.
Not Happy(tm)
New in Wheezy: PMW
One of the things I do with computers is "do stuff with music". I'm not a professional musician by any means, but I do sometimes have a need for some software to do some music editing.
In the past, that meant using GNU LilyPond; and while that's certainly an interesting piece of software, it has some idiosyncracies that have made me dislike it in the past. So when I learned about PMW, written by Philip Hazel (of PCRE and Exim fame) I was intrigued.
PMW has several advantages over lilypond, in my opinion. To name but two: its syntax is less silly, and it takes far less time to convert something from source to graphic, to the extent that I've considered creating an editor which would update the result after every keystroke, something that just isn't possible with lilypond.
The decision to upload pmw into Debian was just a no-brainer, and it's saved me some time since, already. Enjoy!
New in wheezy: NBD named exports and installer support
Just after the release of squeeze, I released nbd 2.9.17, which had a new feature that required some backwards-incompatible change: the ability to specify an export by name, rather than by port number. Obviously, that means that wheezy will be the first release to ship with support for such named exports (although a backport was uploaded to squeeze-backports with support for such a named export). After all, names are that more obvious a way to specify an export than is a meaningless number. The init scripts and root-on-NBD support was updated, although a bugfix was denied for r0 (it will hopefully get into r1).
In addition, during the wheezy cycle I finally finished the partman-nbd support in the installer. With this, it is possible to install Debian to an NBD device on diskless systems, which is nice.
Linux 3.9
... has been released yesterday, apparently. This wouldn't be very special, except that it carries a 'patch' by yours truly. It isn't earthshattering, but hey, I can run 'git log' and find myself, now, in a released kernel.
If that isn't nice.