Sun, 19 May 2013
Whee
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.
Thu, 16 May 2013
Single-stepping init systems
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?
- Boot the system with init=/bin/bash,
- After having booted the system, go to /etc/rcS.d and manually run each and every one of the scripts there in turn. When the system powers off, I know what the problem is.
- Disable the init script that causes the problem, and boot the system normally.
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.
Sat, 04 May 2013
Oops, I did it again...
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?
Mon, 29 Apr 2013
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.
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.
/en/computer/debian/newinwheezy
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!
/en/computer/debian/newinwheezy
Thu, 25 Apr 2013
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)
Tue, 16 Apr 2013
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.
Tue, 09 Apr 2013
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.
Thu, 04 Apr 2013
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.
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|