Ok, I wrote the template of my blog the way I liked. I didn’t consider I would have used wordpress, and this showed out. So, got the first theme that give me some good vibes and Real Simplicity ™, and used that.

One day RedFrame will be out, and I’ll use that. One day.

Posted by mattia as wordpress at 6:41 PM CEST

No Comments »

New Ubuntu version, Feisty Fawn, and I decide to upgrade. A little problem: my /boot is too little. I won’t tell you how little I did it because I’m not that proud of my choice, now. Anyway, I have a 4-disk system managed by LVM, with a single XFS partition over it. luckily, one of them was spare (I planned to put windows on it, then I didn’t need it and was yet free), because XFS can only be grown, never shrinked (funny choice, by the way). So, I had to create a new boot partition, migrate the contents there, and make the old boot partition join the LVM. Since this involved something delicate (yes, that plain, old boot partition) I did things with care. Not enough, since I forgot one thing and had to put the server up again making things locally. Anyway, if you’re brave, you can technically make all that I talked about with your system online and running. How? This is the roadmap:

• partition the new disk. I made a 400 megs boot partition (/dev/sda1) and left the rest for the LVM (/dev/sda2)
• By the way, two other disks (/dev/sdc and /dev/sdd) were one-partition and completely to the power of LVM (so, /dev/sdc1 and /dev/sdc2), whereas another one had the 1G swap (/dev/sdb1), old boot (/dev/sdb2) and one more PV for LVM (/dev/sdb3). So LVM had /dev/sdb3, /dev/sdc1, /dev/sdd1
• Now, mkfs.ext3 the boot partition, mount it, copy the old boot, umount old boot (I remember something like logd or the like was using it: simply shut down the daemon), mount new boot in its place.
• Dear Mr. Grub, which fucked me. REMEMBER to change all the “root” referrings in /boot/grub/menu.lst to reflect the position of the new boot partition. My old value was (hd1,1) because it was /dev/sdb2, but now, with /dev/sda1, everything becaom (hd0,0). Now, you can run grub-install /dev/sda (first disk of the system, bet it is always the best MBR) and grub update the MBR so to point to the new /boot position (in fact it queries the system to look in which device /boot is mounted and work accordingly).
• Add the old /boot and new spare space in the disk to LVM (that is: make /dev/sda2 and /dev/sdb2 useable with pvcreate, then add them to the VG with vgextend, and at last increase the LV which you prefer with physical extents using lvresize - don’t bet on my memory being so good, check this). Now your LV is bigger, and run: xfs_growfs /. This will enlarge in a moment and painlessly your root partition.
• If you did everything good, you should be already ok. Try reboot to check. Now, in my case it stopped because I forgot the menu.lst update (me stupid), but otherwise everything should work correctly. Again, reboot isn’t strictly necessary, it’s just to check everything’s right now (and it is much better than noticing it when some REAL problem force you to reboot)

So, here’s the end, and after that I could update to Feisty with its funny I-do-it-all-myself update manager. End of the Dilbertian Space.

Posted by mattia as boot, lvm, xfs at 10:30 PM CEST

No Comments »

Retrocompatibility is not-bug-prone and meaningful only on good software.
Nobody writes good software.
Thus, retrocompatibility is always meaningless.

Wow.

Posted by mattia as fun at 1:43 PM CEST

No Comments »

I have a Python’s cycle into which I would like to make lambdas:

s = {}
for x in ['stupid', 'genial']:
s[x] = lambda prefix: "%s %s" % (prefix, x)

print s['stupid']('I am')
print s['genial']('You are')

Would you expect this output?

I am stupid
You are genial

No, no. This is the real output:

I am genial
You are genial

Even if I’m happy to be genial too, I wonder what happened. The reply is simple: python’s lambda binding. The x variables isn’t bound when the lambda is constructed, but when the lambda is called. Since both are called only at the end of the cycle, its value is the last value of x, which is 'genial'. Ok, now that we’ve understood what had happened, how can I solve this problem?

If you’re lucky, you’re using Python 2.5 or higher. In this case, they invented functools, and functools.partial:

from functools import partial

s = {}
for x in ['stupid', 'genial']:
  s[x] = partial(lambda prefix, xx: "%s %s" % (prefix, xx), xx = x)

print s['stupid']('I am')
print s['genial']('You are')

Now the lambda takes two arguments, one of which is bound, forceably, to the current value of x. Ok, this solution is not so elegant, but at least is a one-liner. And if you have a lower version of Python? Have fun in decyphering the following one:

s = {}
for x in ['stupid', 'genial']:
  def aux():
    v = x
    return lambda prefix: "%s %s" % (prefix, v)
  s[x] = aux()

print s['stupid']('I am')
print s['genial']('You are')

It works on a simple trick: the aux function put the too inconstant variable x in a local variable, v, then use that one. Since a new local variable is allocated every time, the value of x is saved in that local variable. It is thrown away, once the function exit, but the lambda-binding save the variable, which we can safely get afterwards.

I quite love Python, but, really… some things are really stupid!

Posted by mattia as functools, lambda, python at 2:01 PM CEST

No Comments »