Today, I played at TC Cantincrode in Mortsel, Belgium, in the first round. This is the first year I'm playing tennis competitively, so I wasn't expecting to win by a pretty wide margin. Now while I didn't win, the margin wasn't as wide as I'd expected; 6/4 - 6/3 isn't too bad for the non-ranked beginner that I am. For comparison: I lost my previous match with 6/2 - 6/0, and I was not unhappy about that.
Part of this was due to my opponent (by his own admission) not playing his best; but still, I'm quite happy about my result here.
My next match probably won't be as good. Oh well.
The Linux init systems are a bit in flux at the moment. That is, they're in flux in Debian; outside Debian, most other distributions have stepped away from sysvinit and towards something else (systemd, openrc, or upstart). I've not been a proponent of any switch, though I understand the reasoning, and it probably makes sense for us to switch at some point. But yesterday, the fact that this customer's system was running sysvinit and not systemd or upstart saved me quite a bit.
There's a server. It has one quadcore processor. For reasons that I won't go into here, the customer wants an extra quadcore processor to be added to the system.
After having done so, I power on the system... only to see it power itself off at some point during boot. I did notice some kernel messages fly by just moments before the system would power itself off, but it was impossible for me to read them. So what did I do?
That last bit is, obviously, a bit of an ugly workaround; the better way to fix this issue would have been to debug what the actual issue was, and implement a proper fix. However, I didn't have time for that (the fact that there was need for a second quadcore chip explains how much this system is in use), and the workaround was acceptable for the customer. It is not the first time that this ability to single-step the init system has saved me. The fact that sysvinit is so simplistic is what makes this possible, and I consider that one of its most important features.
Recently, I came into contact with a distribution that uses systemd as its init system (in casu, Arch Linux). I had made a mistake in configuration; I had installed and enabled a graphical login system, but had no xterm or similar available, and had done something else wrong through which I couldn't get a regular shell on the console anymore, either. To fix this, I tried doing something like the above (running with init=/bin/bash and single-stepping the init system), but found that doing so with systemd is nigh impossible. In the end, I knew what exactly the problem was and could disable automatically starting the login manager through removing a symlink, but it brought home the issue that debugging a similar issue when running systemd rather than sysvinit might be a lot harder to do.
We'll see what the future brings.
For (at least) the third time, I managed to register for debconf before registration was actually open. Oops.
I found out that unfortunately, it's not quite certain yet that there will actually be a debcamp this year—and if there is going to be a debcamp, it won't be a full week. Pity. At any rate, I'll be there the whole time, whatever the duration of debcamp.
Since Vaumarcus is closer to Mechelen than Edinburgh (by about 250km), this is going to be the closest debconf for me, ever. And if I could go to Banja Luka by car, I can certainly go to Vaumarcus by car.
Anyone care to join me?
... 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.
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.
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!
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:
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:
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.
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.
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.
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 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.