A Big F*** You to Paul Graham, From Worldwide Software-Support People

Paul Graham: "They'd have sacrificed hundreds of thousands of dollars, perhaps millions, just to be able to deliver more software to users. And you know what? It would have been perfectly safe to let them."

I'm sorry Paul, as a representative of tech-support people worldwide, I have to say: f*** you.

Developers, even fantastically smart ones, don't test enough as it is. If you let them have "push-button release" privileges, the software industry would have an even worse reputation for terrible reliability than it already has, and companies would have to spend millions more in order to support all that crappy code that couldn't wait for two more weeks of testing and certification.

The world would be a better place if developers had to wait two weeks more than they do now, or even two months; maybe there would be less s**t around for others to pick up afterwards.

How to disable access keys in Konqueror

Well, this suggestion by Dimitri on how to disable access keys in Konqueror made my day:

kwriteconfig --file khtmlrc --group "Access Keys" --key Enabled --type bool false

"Now press enter and voilà the access keys are sent to the eternal lands of /dev/null."

Failure of imagination

I really wish I knew what to do.

For the last week, I really wanted to code something up, something new and fresh, and I couldn't figure out what. I periodically feel like this, and I'm reminded that there's tons of things (started and never finished) which would need attention... and even finished ones, like kdelicious, really need some maintenance. But these are boring things; since coding for me is just a hobby, I should really spend it on something fun, right?

Eventually, I decided to install dbxml, something I had postponed for a long time. Following Zeth's excellent guide, I avoided the horrendous pitfalls (typos in testing code? Left there for months?) and managed to set it up properly, even though checkinstall failed to debianize it. (BTW, why don't we have a .deb somewhere? It was originally released in 2003, one would expect that in 5 years somebody would have come forward...)

The good thing about Oracle products is that they come with plenty of documentation; it can be terse, but it's there. (b)dbxml is no exception, so I went through the (excellent) introductory tutorial in a few minutes. Fine. Then I thought "this seems cool, I wonder how could I use it for, maybe some webservice or something"... and the thought died there. My mind had a complete (and utter) failure of imagination. So now I have a very cool xml storage engine with good python bindings, and I don't know what to do with it.

I ended up playing MAME for much of the day.

Bring on Christmas, I need a reboot.

Python "global" weirdness

I'm sure there's a rational explanation for this behaviour, but at the moment is slightly baffling.

class SomeObj:
 def __init__(self):
  self.prop = 1

class SomeClass:
 global objInst
 def __init__(self):
  self.reference = objInst
  self.reference.prop += 1
  
if __name__ == '__main__':
 global objInst
 objInst = SomeObj()
 clsInst = SomeClass()
 print "original:" + str(objInst.prop)
 print "clsInst:" + str(clsInst.reference.prop)

# output:
# >>> x:2
# >>> y:2

This is all good, and expected: you get a reference to a global object and manipulate it. But what happens if you try to rebind that global name straight in the __init__ method?

[..]
class SomeClass:
 global objInst 
 def __init__(self):  
  self.reference = objInst
  self.reference.prop += 1
  objInst = SomeObj()
[..]  
# output:
Traceback (most recent call last):
  File "test.py", line 16, in 
    clsInst = SomeClass()
  File "test.py", line 9, in __init__
    self.reference = objInst
UnboundLocalError: local variable 'objInst' referenced before assignment

And it gets even more weird! If you move the "global objInst" declaration inside the __init__ method, it works as expected: objInst is bound to a new object with a different state from the one in self.reference. But if you keep the declaration at class level, and simply move the rebinding out in a new method (separated from __init__), you don't get an error but python does not bind the global to a new object.

I guess it's somehow all a matter of context, and it probably makes perfect sense to programming-language scientists; it just doesn't to me :)

I'm impressed

Finally we have a Linux system where suspend/resume and even HIBERNATE work out of the box. AND the X-server works as it should, including console-switching. AND it comes with a polished KDE (with a properly-configured kdm), plus an easy upgrade path to KDE4.

Thanks, Kubuntu.