Yeah, that's a helpful response, UPS customer service.
Showing posts with label computers. Show all posts
Showing posts with label computers. Show all posts
Thursday, June 27, 2019
Friday, April 1, 2011
Failing to learn from history again
Learning from history is often hard - without the perfect vision of hindsight, it's easy to overlook the similarities of your current situation with past experience. This isn't at all comforting when one recognised the similarities and dismissed them with "This time, it will be different".
I often write "throw away" code - usually to isolate some specific code path or test some specific case that's currently interesting from the larger system. As the code's initial life expentancy is quite short, I often don't bother with niceties like proper argument parsing or decent error handling. In theory, the technical debt from this never be a problem, just write a little wrapper program, learn what you need, and throw it away.
The scare quotes and "initial life expectancy" phrasing should immediately identify my problem, though. If I didn't but the code in the VCS, the theory might work, but, once the code is there, it's never going to be thrown away, and, since it exists, in a day or a week or a month or something, I'll need something similar, and it's easy enough to just quickly add an option and make the throw script do a little more, and, since it's still just a throw away script, there's still no need to do proper error handling or argument parsing. And, of course, the moment a couple of the command line options become enshrined in a test script or two, the effort required to actually fix things never seems worthwhile, despite the increasingly convoluted "simple quick code" handling things.
Given that I've trodden this path several times before, this week's effort of going from 100 lines of C requiring a single filename to two 250-line interlocked programs, each with complex combinations of options and error handling from the oblivious school (the actual important code of each program is still less than 100 lines each), via a steady stream of "I'll quickly add this", is one of my more impressive examples of failing to heed lessons from the past. Next week, I'll probably spend some time fixing things, although there's still that ever so seductive "it's just one last option and then you can throw it away" voice to deal with.
I often write "throw away" code - usually to isolate some specific code path or test some specific case that's currently interesting from the larger system. As the code's initial life expentancy is quite short, I often don't bother with niceties like proper argument parsing or decent error handling. In theory, the technical debt from this never be a problem, just write a little wrapper program, learn what you need, and throw it away.
The scare quotes and "initial life expectancy" phrasing should immediately identify my problem, though. If I didn't but the code in the VCS, the theory might work, but, once the code is there, it's never going to be thrown away, and, since it exists, in a day or a week or a month or something, I'll need something similar, and it's easy enough to just quickly add an option and make the throw script do a little more, and, since it's still just a throw away script, there's still no need to do proper error handling or argument parsing. And, of course, the moment a couple of the command line options become enshrined in a test script or two, the effort required to actually fix things never seems worthwhile, despite the increasingly convoluted "simple quick code" handling things.
Given that I've trodden this path several times before, this week's effort of going from 100 lines of C requiring a single filename to two 250-line interlocked programs, each with complex combinations of options and error handling from the oblivious school (the actual important code of each program is still less than 100 lines each), via a steady stream of "I'll quickly add this", is one of my more impressive examples of failing to heed lessons from the past. Next week, I'll probably spend some time fixing things, although there's still that ever so seductive "it's just one last option and then you can throw it away" voice to deal with.
Saturday, January 23, 2010
How not to setup your firewall
(This is of course an entirely hypothetical set of notes, since it's inconceivable [1] that I would make any of these errors).
For the purposes of this exercise, we assume a gateway machine, running a simple firewall, which we want to use to drop various packets on the floor - such as those from machines particiapting in a distributed brute for ssh attack, for instance. We assume there are several scripts managing the blocked list. For best effect, your gateway box should be mounting a few directories via nfs from another machine.
[1] Which means exactly what I think it means.
For the purposes of this exercise, we assume a gateway machine, running a simple firewall, which we want to use to drop various packets on the floor - such as those from machines particiapting in a distributed brute for ssh attack, for instance. We assume there are several scripts managing the blocked list. For best effect, your gateway box should be mounting a few directories via nfs from another machine.
- Ensure that packets between the gateway box and the file server need to traverse the blocked list first.
- Don't lock properly when adding new IPs to the firewall. This ensures that, under load, you can add large numbers of duplicate entries to the list.
- Have every packet traverse the blocked list twice.
[1] Which means exactly what I think it means.
Wednesday, May 6, 2009
Code Mainentance
One of the problems with an under-resourced development environment, such as the one I'm involved in at iTL, is the lack of decent code review. Consequently, the code base ends up with dirty little secrets, like the routines to automatically identify the calibration cube, a awkwardly tangled implementation of what still is actually quite a good idea. It's a chunk of code I'm both perversely proud of, and terrified someone else will look at and thus call me out as a total fraud.
Despite this, it actually works pretty well almost all the time, which is unfortunately an "almost" too many, so today was spent debugging this dirty little secret, which is never that much fun. It's easier than it may sound, though. Most programmers will have had the experience of looking at old code and thinking "How could this possibly ever work?", and most programmers will also have experienced looking at bits of old code and realizing "Oh, that actually quite a nifty trick". For me, reading this code tends to be a sequence of a's followed by b's followed by a's and so on. When the sequence doesn't end at b, it's probably a bug. The retroactive ego-boosting and deflating does make it a slightly bizarre experience, though, and not one I'm keen to repeat anytime soon.
Despite this, it actually works pretty well almost all the time, which is unfortunately an "almost" too many, so today was spent debugging this dirty little secret, which is never that much fun. It's easier than it may sound, though. Most programmers will have had the experience of looking at old code and thinking "How could this possibly ever work?", and most programmers will also have experienced looking at bits of old code and realizing "Oh, that actually quite a nifty trick". For me, reading this code tends to be a sequence of a's followed by b's followed by a's and so on. When the sequence doesn't end at b, it's probably a bug. The retroactive ego-boosting and deflating does make it a slightly bizarre experience, though, and not one I'm keen to repeat anytime soon.
Friday, March 27, 2009
The benefits of expressivity
This is the result of a chain of thought kicked off by reading "The fallacy of high level languages".
While I agree with many points made, it did start me thinking about how the debate about high and low level language is framed almost entirely in terms of the main developers. This is probably since most people in the debate are heavily involved in commercial software development. One of the great strengths of FLOSS development is the existence of the casual contributor, the person who submits a fix to an bug they find personally annoying or such. They often are more interested in using the program than developing it, but they have the skills to make the occasional contribution.
Consequently, ease of contribution is a factor that is worth considering, and, based on my personal experience, the easier it is to get up to speed on the code around the problem, the more likely I am to write and submit a patch. Expressive, compact code is easier for me to get my head around, and thus easier for me to contribute to.
Of course, expressive code is only partly function of language choice, often being more a matter of developer discipline (nothing can save one from writing crap code, after all).
Compactness is just as important though. When dealing with a new codebase, the less I have to keep in my head in trying to follow the logic flow of the path of interest, the better. Here, language and library choices are important, and this is where high level languages can really shine.
Indeed, pretty much all of the arguments for the maintainability of code written in a high level language are much more relevant for casual contributers, who can't fall back on the sort of overview somebody who's worked extensively with the code base will have, than it is for the major developers.
While I agree with many points made, it did start me thinking about how the debate about high and low level language is framed almost entirely in terms of the main developers. This is probably since most people in the debate are heavily involved in commercial software development. One of the great strengths of FLOSS development is the existence of the casual contributor, the person who submits a fix to an bug they find personally annoying or such. They often are more interested in using the program than developing it, but they have the skills to make the occasional contribution.
Consequently, ease of contribution is a factor that is worth considering, and, based on my personal experience, the easier it is to get up to speed on the code around the problem, the more likely I am to write and submit a patch. Expressive, compact code is easier for me to get my head around, and thus easier for me to contribute to.
Of course, expressive code is only partly function of language choice, often being more a matter of developer discipline (nothing can save one from writing crap code, after all).
Compactness is just as important though. When dealing with a new codebase, the less I have to keep in my head in trying to follow the logic flow of the path of interest, the better. Here, language and library choices are important, and this is where high level languages can really shine.
Indeed, pretty much all of the arguments for the maintainability of code written in a high level language are much more relevant for casual contributers, who can't fall back on the sort of overview somebody who's worked extensively with the code base will have, than it is for the major developers.
Wednesday, February 18, 2009
DVCS musings
Every so often, there are a spate of blog posts ragging on git. Probably because of who wrote it, and it's importance to the kernel, negative criticism of git tends to get rather widely broadcast, and attracts the same sort of stupid fanboy'ish flamewars that plague many bits of the free software ecosystem, and there always seems to be a "my DVCS is better than yours" flamewar just waiting in the wings to really get the discussion going.
To me, much of the discussion feels very much like the old emacs vs vi flamewars, before they became parodies of themselves. Given the trend towards easy interoperability, with tools such as git-svn, the bzr svn plugin, the various git fastimport helpers, and so forth, increasingly, the choice of (D)VCS is as independent of the other people in the project as the choice of editor. In a few years, hopefully people will actually realise this, and the whole debate will calm down. At which point, we can all return to arguing about the important things, like editors.
To me, much of the discussion feels very much like the old emacs vs vi flamewars, before they became parodies of themselves. Given the trend towards easy interoperability, with tools such as git-svn, the bzr svn plugin, the various git fastimport helpers, and so forth, increasingly, the choice of (D)VCS is as independent of the other people in the project as the choice of editor. In a few years, hopefully people will actually realise this, and the whole debate will calm down. At which point, we can all return to arguing about the important things, like editors.
Wednesday, January 14, 2009
Gtk+ lessons
I learnt of a couple of interesting gtk+ quirks over the last couple of days while hacking on Sutekh. Both rather surprised me, so are thus worth noting for future reference.
The first quirk is something I still don't fully understand. For various reasons[1] Sutekh uses strings to display the numbers with markup in the interface. I recently added a tweak so that these would sort numerically, rather than lexically. Since this involves stripping off the markup and converting to an integer, the sort is not lightning fast, but still acceptable. Unfortunately, adding the tweak the obvious way doubled the length of time to run the tests on the model, despite the model being unsorted by default. I've been unable to track down why this affects the tests so badly, since we shouldn't be using that code path at all. Fortunately, a simple lazy work-around exists, which is to tweak the sorting in a slightly less obvious way, and avoid it impacting the test suit.
The second quirk is something I do now understand, although the behaviour did surprise me. Sutekh is capable of generating very large gtk+ models (using "show all cards, show expansions + card sets" and editable options, it's easy to end up with a gtk.TreeStore containing more than 100000 entries). Loading these was unacceptably slow, with most of the time spent adding rows to the model, despite using the usual recommended tricks of disabling notifications and such while adding the rows.
It turns out that the underlying data structure for the gtk.TreeStore is glib's n-ary tree, g_node.
g_node, however, represents each list of children as a singly linked list from the parent. Consequently, appends into long lists are slow, since you have to walk to the end of the list. There's the obvious work-around, which is to insert thing in reverse using prepend, and it is indeed significantly faster, but you'd think this would be mentioned prominently in the docs, rather than requiring one to grub around in the glib code.
[1] i.e. We haven't got around to fixing this the right way yet.
The first quirk is something I still don't fully understand. For various reasons[1] Sutekh uses strings to display the numbers with markup in the interface. I recently added a tweak so that these would sort numerically, rather than lexically. Since this involves stripping off the markup and converting to an integer, the sort is not lightning fast, but still acceptable. Unfortunately, adding the tweak the obvious way doubled the length of time to run the tests on the model, despite the model being unsorted by default. I've been unable to track down why this affects the tests so badly, since we shouldn't be using that code path at all. Fortunately, a simple lazy work-around exists, which is to tweak the sorting in a slightly less obvious way, and avoid it impacting the test suit.
The second quirk is something I do now understand, although the behaviour did surprise me. Sutekh is capable of generating very large gtk+ models (using "show all cards, show expansions + card sets" and editable options, it's easy to end up with a gtk.TreeStore containing more than 100000 entries). Loading these was unacceptably slow, with most of the time spent adding rows to the model, despite using the usual recommended tricks of disabling notifications and such while adding the rows.
It turns out that the underlying data structure for the gtk.TreeStore is glib's n-ary tree, g_node.
g_node, however, represents each list of children as a singly linked list from the parent. Consequently, appends into long lists are slow, since you have to walk to the end of the list. There's the obvious work-around, which is to insert thing in reverse using prepend, and it is indeed significantly faster, but you'd think this would be mentioned prominently in the docs, rather than requiring one to grub around in the glib code.
[1] i.e. We haven't got around to fixing this the right way yet.
Tuesday, December 2, 2008
Sutekh 0.6.0 released
After far too long, we finally got the current trunk to a state where we were happy to release. Unlike the previous stable releases, we decided that this one was worth a bigger splash, and announced it on the VTES newsgroup.
As such releases go, that seems to have been a success, and I've spent the last couple of days obsessively watching the sourceforge downloads counter tick up.
The increasing number of downloads, however, has not been accompanying by any comparable flood of queries or requests. As a measure of validation that people are using out work, this leaves a fair bit to be desired. Typical, really. Users are never around when you want them, and often there to complain when you don't.
As such releases go, that seems to have been a success, and I've spent the last couple of days obsessively watching the sourceforge downloads counter tick up.
The increasing number of downloads, however, has not been accompanying by any comparable flood of queries or requests. As a measure of validation that people are using out work, this leaves a fair bit to be desired. Typical, really. Users are never around when you want them, and often there to complain when you don't.
Tuesday, June 3, 2008
Curiosity is a funny thing
For various reasons, many to do with my instinctive distrust of university IT departments (what can I say, I've been around academia for too long), I find myself responsible for our departments web-server.
The web-server hosts various things, such as the course pages, a wiki for the South African OR society and a few other things.
Unsurprisingly, pursuing the logs reveals a great deal of refer spam, and, unsurprisingly, I have a set rewrite rules to deny access to obviously bad refers, and various automated steps in place to keep the blacklist updated, and some manual processes, since not everything can be automated. This does have the side effect that I have a automatically updated record of referrer spam in our logs. Which is where curiosity kicks in and asks "I wonder if there are any interesting stats to be gather from this?"
Perhaps fortunately, the data isn't well organised for analysis - I can't readily extract temporal information or frequencies of repeated patterns without correlating stuff against the logs, which is more effort than it's worth, but some simple keyword grepping is enough t at least roughly break things down into categories, which is already interesting.
So, based pretty much on the junk seem so far this year, dip's stats are:
Leading the way, at a little under 35%, are gambling related terms, with poker the big winner, followed by various spellings of blackjack.
Insurance surprisingly comes next - accounting for just over 20%. Medical and health insurance are the major keywords, with the vehicle insurance terms running a fairly distant third.
Next, at just under 10%, are various loan and debt management terms. Bills and debt are the most popular keywords here, with loans close behind.
Viagra and such account for around 7.5%
Porn does surprisingly badly, only accounting for around 5% of the cases - with a huge variety of terms used.
The rest is a mish-mash of music sites, link sites and various other junk., with nothing really worth singling out into a single category, although 1% is taken up by cigar and cigarette related links, which I find somewhat bizarre.
Well, at least I'm no longer that curious - in due course, no doubt, the bug will bite again, and I'll do the correlation against the logs, in which case, dear innocent reader, you shall be confronted by graphs (and even possibly pie-charts).
The web-server hosts various things, such as the course pages, a wiki for the South African OR society and a few other things.
Unsurprisingly, pursuing the logs reveals a great deal of refer spam, and, unsurprisingly, I have a set rewrite rules to deny access to obviously bad refers, and various automated steps in place to keep the blacklist updated, and some manual processes, since not everything can be automated. This does have the side effect that I have a automatically updated record of referrer spam in our logs. Which is where curiosity kicks in and asks "I wonder if there are any interesting stats to be gather from this?"
Perhaps fortunately, the data isn't well organised for analysis - I can't readily extract temporal information or frequencies of repeated patterns without correlating stuff against the logs, which is more effort than it's worth, but some simple keyword grepping is enough t at least roughly break things down into categories, which is already interesting.
So, based pretty much on the junk seem so far this year, dip's stats are:
Leading the way, at a little under 35%, are gambling related terms, with poker the big winner, followed by various spellings of blackjack.
Insurance surprisingly comes next - accounting for just over 20%. Medical and health insurance are the major keywords, with the vehicle insurance terms running a fairly distant third.
Next, at just under 10%, are various loan and debt management terms. Bills and debt are the most popular keywords here, with loans close behind.
Viagra and such account for around 7.5%
Porn does surprisingly badly, only accounting for around 5% of the cases - with a huge variety of terms used.
The rest is a mish-mash of music sites, link sites and various other junk., with nothing really worth singling out into a single category, although 1% is taken up by cigar and cigarette related links, which I find somewhat bizarre.
Well, at least I'm no longer that curious - in due course, no doubt, the bug will bite again, and I'll do the correlation against the logs, in which case, dear innocent reader, you shall be confronted by graphs (and even possibly pie-charts).
Friday, May 30, 2008
This Week
So, what happened in the past week?
On Monday, there was VTES at Phillip's house. I tried out 3 decks, and, while I didn't do particularly well, I managed to oust my prey in two games, which was a fair effort for the evening
Tuesday, I was off sick
On Wednesday, I attended Geekdinner (pictures here), which was pretty enjoyable, despite riding my motorcycle in the rain (and, please note, the sound of the rain isn't soothing when you're on a bike). The trip back was enlivened by a cylinder cutting out, but I made it home alive [1].
My UPS's finally arrived, so I spent quite some time on Thursday prodding at them. Annoyingly, there's a bug in nut 2.2.1, which is the currently latest packaged version, which breaks support for several megatec usb UPS's, such as my new ones, so I had to roll my own nut 2.2.2 backport, which was not quite as simple as I would have liked.
Today (Friday) was mainly spent on the final stages of setting up our rather idle UltraSparc as a buildbot for numpy. After some annoying surprises (a variant of issue 198 amongst other things), and some fussing around to get multiple chroots installed (so we can test both g77 and gcc4's gfortran), things finally seem to be working properly (see this and this for example).
Workwise, we're testing the latest version of the SPG system, so much bug fixing. I loathed at qt a fair bit, but managed to get most issues resolved. We've also been poking at the robot-SPG communication, which has uncovered some interesting issues with the path planner, so , even there, I can claim to have had a reasonably productive week.
[1] I've always liked that song, the actual riding in the rain less so, though.
On Monday, there was VTES at Phillip's house. I tried out 3 decks, and, while I didn't do particularly well, I managed to oust my prey in two games, which was a fair effort for the evening
Tuesday, I was off sick
On Wednesday, I attended Geekdinner (pictures here), which was pretty enjoyable, despite riding my motorcycle in the rain (and, please note, the sound of the rain isn't soothing when you're on a bike). The trip back was enlivened by a cylinder cutting out, but I made it home alive [1].
My UPS's finally arrived, so I spent quite some time on Thursday prodding at them. Annoyingly, there's a bug in nut 2.2.1, which is the currently latest packaged version, which breaks support for several megatec usb UPS's, such as my new ones, so I had to roll my own nut 2.2.2 backport, which was not quite as simple as I would have liked.
Today (Friday) was mainly spent on the final stages of setting up our rather idle UltraSparc as a buildbot for numpy. After some annoying surprises (a variant of issue 198 amongst other things), and some fussing around to get multiple chroots installed (so we can test both g77 and gcc4's gfortran), things finally seem to be working properly (see this and this for example).
Workwise, we're testing the latest version of the SPG system, so much bug fixing. I loathed at qt a fair bit, but managed to get most issues resolved. We've also been poking at the robot-SPG communication, which has uncovered some interesting issues with the path planner, so , even there, I can claim to have had a reasonably productive week.
[1] I've always liked that song, the actual riding in the rain less so, though.
Tuesday, March 25, 2008
Misc Geekery
(or wasting time with elementtree)
Like many people, I have attempted and pretty much utterly failed to maintain the classic list of links style web-page. This is most notable example is my list of web-comics I read, which is both out of date, and horribly incomplete.
Part of this, is, of course, the effort to manually create the webpages needed, and fill in the content. However, since galeon's bookmark are stored in nicely structured xml, and I group the comics I follow in a not completely broken manner, I hit on the bright idea of pulling the bookmarks out using elementtree, and, furthermore, I can use galeon's bookmark notes to do the documenting about the comics.
So, after a couple of hours of prodding (much of it spent trying to get an overly complex design working before an important light-bulb went on), I now have a little python script that pulls all the data out, and writes a nice, standards conforming html file with all details - Now I just need to actually go through and sort out my comics bookmarks a bit, and I'll actually have a much more maintainable way of generating the list.
Of course, when I eventually move away from galeon (I've been using epiphany exclusively on my laptop for a while now, so it's likely to be not too far off), I'll have to tweak the script, and probably fiddle with the bookmark's conversion a bit to get all the comments across properly, but such is progress.
ah, the idle amusements of a life around computers.
(and to think I'd planned to spent the evening working on Sutekh)
Like many people, I have attempted and pretty much utterly failed to maintain the classic list of links style web-page. This is most notable example is my list of web-comics I read, which is both out of date, and horribly incomplete.
Part of this, is, of course, the effort to manually create the webpages needed, and fill in the content. However, since galeon's bookmark are stored in nicely structured xml, and I group the comics I follow in a not completely broken manner, I hit on the bright idea of pulling the bookmarks out using elementtree, and, furthermore, I can use galeon's bookmark notes to do the documenting about the comics.
So, after a couple of hours of prodding (much of it spent trying to get an overly complex design working before an important light-bulb went on), I now have a little python script that pulls all the data out, and writes a nice, standards conforming html file with all details - Now I just need to actually go through and sort out my comics bookmarks a bit, and I'll actually have a much more maintainable way of generating the list.
Of course, when I eventually move away from galeon (I've been using epiphany exclusively on my laptop for a while now, so it's likely to be not too far off), I'll have to tweak the script, and probably fiddle with the bookmark's conversion a bit to get all the comments across properly, but such is progress.
ah, the idle amusements of a life around computers.
(and to think I'd planned to spent the evening working on Sutekh)
Tuesday, January 22, 2008
New Toy
I have a rather old laptop. Considering that I acquired it at the end of 2001, it's served me exceedingly well, and proved rather robust. All good things must come to and end, and, although I've kept the laptop alive despite a gradually failing hard-drive for some time, the screen, which never quite recovered from water damage due to being caught in some rather heavy rain on the bike, eventually gave up the ghost.
Thus I have a new, shiny, fast toy. I acquired a Fujitsu-Siemens Li1718 laptop (dual-core 1.78Ghz Pentium, 160GB harddisk, ATI graphics, etc) (pictures here). Overall, a very nice shiny toy.
My home desktop machine is still marginally more powerful, but, considering I only spent 7000 rand on the laptop, and I spent slightly more than that on the desktop machine 18 months ago, it's quite a testament to how technology prices have continued to fall.
Installing Debian was quite painless - The latest etch installer had minimal trouble, and upgrading to lenny was completely painless, thanks to doing it at campus, with a nice fast local mirror available (I've not been tracking testing for a while, so I thought this was a good time to start doing so again). The only thing not working out of the box is the wireless network card, but there are patches for madwifi floating around, so hopefully that will fix itself in due course, and I'm not such a heavy wireless user that it really matters. The graphics card is currently not accelerating OpenGL stuff, but the current work on the DRI drivers should solve that fairly soon. There was a time when I would have booted into the windows partition just to check things, but these days my confidence in Linux's hardware support is such that I no longer bother, so I honestly don't know what was pre-installed on the machine.
And, with Eskom's current failure to provide the country with reliable power, it is nice to once again have a machine with a battery life that can be measured in more than seconds (Of course, this means I lose an excuse not to do work, but the toy's worth it.)
Thus I have a new, shiny, fast toy. I acquired a Fujitsu-Siemens Li1718 laptop (dual-core 1.78Ghz Pentium, 160GB harddisk, ATI graphics, etc) (pictures here). Overall, a very nice shiny toy.
My home desktop machine is still marginally more powerful, but, considering I only spent 7000 rand on the laptop, and I spent slightly more than that on the desktop machine 18 months ago, it's quite a testament to how technology prices have continued to fall.
Installing Debian was quite painless - The latest etch installer had minimal trouble, and upgrading to lenny was completely painless, thanks to doing it at campus, with a nice fast local mirror available (I've not been tracking testing for a while, so I thought this was a good time to start doing so again). The only thing not working out of the box is the wireless network card, but there are patches for madwifi floating around, so hopefully that will fix itself in due course, and I'm not such a heavy wireless user that it really matters. The graphics card is currently not accelerating OpenGL stuff, but the current work on the DRI drivers should solve that fairly soon. There was a time when I would have booted into the windows partition just to check things, but these days my confidence in Linux's hardware support is such that I no longer bother, so I honestly don't know what was pre-installed on the machine.
And, with Eskom's current failure to provide the country with reliable power, it is nice to once again have a machine with a battery life that can be measured in more than seconds (Of course, this means I lose an excuse not to do work, but the toy's worth it.)
Monday, October 22, 2007
White Russian (or "wasn't I meant to do something here?")
I finally got around to flashing my WRT54GL with the rather spiffy openwrt firmware (White Russian 0.9 release). Considering I had been intending to do so ever since I got the thing early in the year, this represents a rather impressive feat of procrastination on my part (although not yet an awe-inspiring feat, such as my intention to finish working through the Communication Theory text book I bought while doing my M.)
The process was competely painless. In fact, it was so painless I'm almost feeling cheated. Isn't getting Linux running on exotic hardware the way you proven your geekiness? In addition to the extremely simple install (point router at firmware, press upgrade, wait), the upgrade process retained the wireless network settings, so I didn't even have to configure anything to get my wireless network going again.
Very convenient.
Now, having finally flashed the the thing, I can move doing a proper compartmentalised wireless setup up my todo list. Check back in six months or so.
The process was competely painless. In fact, it was so painless I'm almost feeling cheated. Isn't getting Linux running on exotic hardware the way you proven your geekiness? In addition to the extremely simple install (point router at firmware, press upgrade, wait), the upgrade process retained the wireless network settings, so I didn't even have to configure anything to get my wireless network going again.
Very convenient.
Now, having finally flashed the the thing, I can move doing a proper compartmentalised wireless setup up my todo list. Check back in six months or so.
Saturday, September 29, 2007
Futurex
I'm sorely tempted to write a really lengthy rant about just how bad Futurex was this year, but, considering that such a rant would take me longer to develop to the desired finely honed level of virulence than I actually spent at Futures, I'll restrain myself to a brief, less well thought out rant.
If you had' got the message from the above, Futurex was bad. It was dire. As Mark rather aptly summed it up "It was a good squib short of a damp squib". It would be much easier to list the things they got right rather than the things they got wrong, expect there isn't anything to list as being noticeably right. It felt half-baked, unprepared and poorly thought out. No map, no logic to the positioning of the stalls, only a couple of interesting things on display, amid a lot of just meh. Even the securex side of it didn't have anything interesting.
Basically, unless I am assured by several trustworthy people that the next one is a massive improvement, I'll probably not be attending Futurex again, which is a pity, because, at one time, it used to actually be a useful event.
If you had' got the message from the above, Futurex was bad. It was dire. As Mark rather aptly summed it up "It was a good squib short of a damp squib". It would be much easier to list the things they got right rather than the things they got wrong, expect there isn't anything to list as being noticeably right. It felt half-baked, unprepared and poorly thought out. No map, no logic to the positioning of the stalls, only a couple of interesting things on display, amid a lot of just meh. Even the securex side of it didn't have anything interesting.
Basically, unless I am assured by several trustworthy people that the next one is a massive improvement, I'll probably not be attending Futurex again, which is a pity, because, at one time, it used to actually be a useful event.
Monday, September 17, 2007
Playing with panoramas
As anyone looking at my photos might notice, I'm rather keen on playing with my digital camera.
It's probably inevitable that, at some point, I'd be tempted by the idea of creating panorama shots. And, as people who attended my CTPUG talk on PIL can testify, I've sued very simple techniques (simple correlation matching, and PIL's blend stitching, without camera corrections) to demonstarate ideas in on a few occasions before, but never got around to actually doing all the heavy lifting needed to create proper panoramas. Fortunately, the beauty of open source software means I don't need to.
I've been aware of panorama tools for a few years, without ever getting around to playing with them. This changed when I recently discovered hugin, a nice GUI frontend for all the various panorama tools stages. The frontend is pretty intuitive, although it took me a while to grasp adding horizontal and vertical guidelines to help prevent unnecessary curvature of the horizon, and the result, when combined with enblend's stitching, is pretty impressive, I think. See this for example.
So, in short, expect more panorama's from me.
It's probably inevitable that, at some point, I'd be tempted by the idea of creating panorama shots. And, as people who attended my CTPUG talk on PIL can testify, I've sued very simple techniques (simple correlation matching, and PIL's blend stitching, without camera corrections) to demonstarate ideas in on a few occasions before, but never got around to actually doing all the heavy lifting needed to create proper panoramas. Fortunately, the beauty of open source software means I don't need to.
I've been aware of panorama tools for a few years, without ever getting around to playing with them. This changed when I recently discovered hugin, a nice GUI frontend for all the various panorama tools stages. The frontend is pretty intuitive, although it took me a while to grasp adding horizontal and vertical guidelines to help prevent unnecessary curvature of the horizon, and the result, when combined with enblend's stitching, is pretty impressive, I think. See this for example.
So, in short, expect more panorama's from me.
Friday, July 13, 2007
History of a bug
(or how a problem with our HP printer earned me so money)
The story starts some years ago, where the department bought a rather nice duplex HP4000 printer. For quite some time, I had it happily setup using the on board Postscript interpreter. Then Matlab started producing Postscript 3 graphs, and the on board interpreter didn't handle this, and there was some issue with the newer Matlab's Postscript 2 graphs exceeding the memory capacity of the printer.
Ah-ha, says I, ghostscrpt has good support for the HP printers, so I'll push everything through ghostscript and get PCL output to feed the printer. The only issue was the that the ljet4d driver did not handle Postscript's /Tumble command at all, which was inconvenient, Still, I went with the setup, and, all in all, it worked pretty well, except that, every now and then, we would run into the issue of not being able to bring with /Tumble.
Then, while digging for something, I discovered HP's list of PCL commands, and saw that, supporting /Tumble was quite simple on the PCL side. Thus informed, I spent some time digging into ghostscript's code, and created a patch (which was not very clean at that stage), which did the job. I sent the patch off to the ghosctscript ailing list, and forgot about it for a while.
Sometime later (early 2005), I upgraded the print server, and had to adapt my patch to the new version of ghostscript. In the process, I cleaned up several things, refactoring it to move the Postscipt parsing of /Tumble down into the core, and generally getting something I was much happier with. Since the post to the mailing list yielded no response, I shoved the patches in ghostscript's bugzilla (one bug for the parsing refactoring and one for the changes to the PCL drivers). Since I now had a working setup, I didn't push the issue at all.
Forward to 2007 - I again upgraded the print server, and need to port my patches. At the same time, somebody on the ghostscript side is assigned to the bugs I submitted with the previous patches, and promptly closes them as being old. After complaining that this was not a valid reason to close the bugs, I was told that the parser changes were unacceptable (a decision I disagree with, personally, but it's not my call), but that they would consider an updated fix to the laserjet drivers. There was also a not that the bug had a bounty, which I assumed would be some nomial sum, and didn't note particularly.
After some delays on my side, I eventually found an afternoon and put together yet another version of the patch, and submitted it last week. Thus, I was somewhat surprised when they contacted this week and told me that the bounty was $500. Additionally, they were quite quick about processing the payment, an, at 14:00 this afternoon, my bank contacted me to let me know that the money had arrived.
Overall, I feel quite pleased with the final result - despite the long time frame, it was never more than a couple of afternoon's work and I've had a solution in place for my problem most of the time, but, finally, next time I upgrade, I won't need to worry about this. Of course, I may also no longer have a printer to which the patch applies, but so be it.
The story starts some years ago, where the department bought a rather nice duplex HP4000 printer. For quite some time, I had it happily setup using the on board Postscript interpreter. Then Matlab started producing Postscript 3 graphs, and the on board interpreter didn't handle this, and there was some issue with the newer Matlab's Postscript 2 graphs exceeding the memory capacity of the printer.
Ah-ha, says I, ghostscrpt has good support for the HP printers, so I'll push everything through ghostscript and get PCL output to feed the printer. The only issue was the that the ljet4d driver did not handle Postscript's /Tumble command at all, which was inconvenient, Still, I went with the setup, and, all in all, it worked pretty well, except that, every now and then, we would run into the issue of not being able to bring with /Tumble.
Then, while digging for something, I discovered HP's list of PCL commands, and saw that, supporting /Tumble was quite simple on the PCL side. Thus informed, I spent some time digging into ghostscript's code, and created a patch (which was not very clean at that stage), which did the job. I sent the patch off to the ghosctscript ailing list, and forgot about it for a while.
Sometime later (early 2005), I upgraded the print server, and had to adapt my patch to the new version of ghostscript. In the process, I cleaned up several things, refactoring it to move the Postscipt parsing of /Tumble down into the core, and generally getting something I was much happier with. Since the post to the mailing list yielded no response, I shoved the patches in ghostscript's bugzilla (one bug for the parsing refactoring and one for the changes to the PCL drivers). Since I now had a working setup, I didn't push the issue at all.
Forward to 2007 - I again upgraded the print server, and need to port my patches. At the same time, somebody on the ghostscript side is assigned to the bugs I submitted with the previous patches, and promptly closes them as being old. After complaining that this was not a valid reason to close the bugs, I was told that the parser changes were unacceptable (a decision I disagree with, personally, but it's not my call), but that they would consider an updated fix to the laserjet drivers. There was also a not that the bug had a bounty, which I assumed would be some nomial sum, and didn't note particularly.
After some delays on my side, I eventually found an afternoon and put together yet another version of the patch, and submitted it last week. Thus, I was somewhat surprised when they contacted this week and told me that the bounty was $500. Additionally, they were quite quick about processing the payment, an, at 14:00 this afternoon, my bank contacted me to let me know that the money had arrived.
Overall, I feel quite pleased with the final result - despite the long time frame, it was never more than a couple of afternoon's work and I've had a solution in place for my problem most of the time, but, finally, next time I upgrade, I won't need to worry about this. Of course, I may also no longer have a printer to which the patch applies, but so be it.
Sunday, July 8, 2007
On Failure Modes
People designing systems don't think enough about failure modes. Failures are annoying, but you need to design the system to fail gracefully. It is exceedingly annoying when this doesn't happen.
A recent example, that is of particular concern, as it bite me twice yesterday, it the access control system at Stellenbosch. When the system is down for a particular building, there isn't anyone authorized to open the other doors into the building, thus one is forced to wait until the technicians responsible for the access control system respond. Since this is naturally after hours, this takes some time, and is less than ideal when all you want to do is dive into the building quickly to collect something. A failure mode not designed to enable people to do what they need.
I'd feel a lot happier about the whole experience if I thought there was some chance the system would improve.
A recent example, that is of particular concern, as it bite me twice yesterday, it the access control system at Stellenbosch. When the system is down for a particular building, there isn't anyone authorized to open the other doors into the building, thus one is forced to wait until the technicians responsible for the access control system respond. Since this is naturally after hours, this takes some time, and is less than ideal when all you want to do is dive into the building quickly to collect something. A failure mode not designed to enable people to do what they need.
I'd feel a lot happier about the whole experience if I thought there was some chance the system would improve.
Saturday, June 23, 2007
CTPUG 4
So, another CTPUG meeting successfully dealt with.
My pygame talk did not go as smoothly as I had planned, it must be said, and no-one laughed at the "Seriously, who did not see that coming" subtitle, which is a great pity, as I thought that joke was quite good. My demonstration of broken threading refused to break, which was most strange, since it broke quite happily here at home. Given the two in the morning origin of parts of the talk, I think it went as well as can be expected.
Kevin's talk on numpy went over quite well, and sets him up t be roped into to talking at the next one as well. One less talk to find.
After the pygame meeting, most of the attendees migrated to a pleasant little pizza place on Long street, where we had pizza, at quite reasonable cost, it must be said. I wish I could remember the places name, because it is worth remembering.
My pygame talk did not go as smoothly as I had planned, it must be said, and no-one laughed at the "Seriously, who did not see that coming" subtitle, which is a great pity, as I thought that joke was quite good. My demonstration of broken threading refused to break, which was most strange, since it broke quite happily here at home. Given the two in the morning origin of parts of the talk, I think it went as well as can be expected.
Kevin's talk on numpy went over quite well, and sets him up t be roped into to talking at the next one as well. One less talk to find.
After the pygame meeting, most of the attendees migrated to a pleasant little pizza place on Long street, where we had pizza, at quite reasonable cost, it must be said. I wish I could remember the places name, because it is worth remembering.
Friday, June 8, 2007
So I signed up to Facebook.
Why? Idle curiosity, mainly, but I've done many things because of that, so that's not too unusual.
My first impression are mixed, and thus so the are the following comments:
Why? Idle curiosity, mainly, but I've done many things because of that, so that's not too unusual.
My first impression are mixed, and thus so the are the following comments:
- WTF is up with the "find friends in your address book" thing? Who though having facebook trawl my contacts list for people would be a good idea?
- The interface is often clunky
- "The wall" looks like an astonishing bad invention. It seems to want to be somewhere between a forum and a set of blog comments, but without the ability to compartmentalise into threads that make conversations manageable in either.
- What people are willing to post on the wall is quite eye-opening at times
- YA online status thingy to play with
- Randomly searching for various people eats up a lot ore time than one would think
- Finding the person you're looking for can be quite hard
- Following links in various people's social networks is another dangerous time sink.
- The temptation to push misleading information into "how one met" and such fields is quite strong.
Thursday, June 7, 2007
Subscribe to:
Posts (Atom)