pvaneynd

For some reason my involvement with Fosdem is going up, not down.

So I will certainly be there, find me hacking the network again. Learning QoS in a trial by fire :).

I'm experimenting with zfs at home, for the moment on top of my md/lvm setup, and I ran out of disk space. Growing the lv is pretty easy:

frost:~# lvextend --size +110G /dev/new-vg/zfs-test
  Extending logical volume zfs-test to 120.00 GiB
  Logical volume zfs-test successfully resized
frost:~# zpool list
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfs-pool  9.94G  9.78G   161M    98%  1.00x  ONLINE  -

Hmm it did not notice the 110GB extra, so I did:

frost:~# zpool export zfs-pool
frost:~# zpool import zfs-pool
frost:~# zpool list
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zfs-pool   120G  9.78G   110G     8%  1.00x  ONLINE  -

so simply doing an import/export is enough.

I'm looking at zfs to have a better idea of what btrfs will mean in the future for us.

With a lot of help from Faré and James Y Knight we have now the incredible disappearing common-lisp-controller v7. We went from 617 to 267 lines which in fact are only 193 lines excluding comments and empty lines...

Using the new features of cl-asdf version 1.500 and higher the implementation of CLC is now merely setting a few variables and putting a few files into place. As an added bonus I added clbuild integration, so now people can download and update libraries with ease.

Still todo:

• there is an bug (#567912) that the first call to (clc:clc-require :<foo>) will fail with clisp due to a loop where there is no looping...
• We still need to find a way to precompile libraries
• Because asdf is now taking care of placing the fasl file in the correct place, we cannot remove fasls for a specific implementation or library, so we nuke them all. Not optimal.

.

Still a nice improvement, I hope to find some time at fosdem to work on the other issues...

Following the announcement of the source+throw away binaries route for uploading packages I've had a brief discussion with our FTP team.

The implications of the new method would be that if you upload a package it will automatically be recompiled from source by using the packages already in the system.

For cmucl which needs cmucl to recompile itself it means that we can only use the previous version of cmucl in the archive, not the one we are just uploading. This won't work as the compiling cmucl needs to be hand-patched to be more 'like' the new version, otherwise you cannot rebuild it.

The conclusion of this discussion is that systems like cmucl are no longer possible under this new system.

The FTP team suggested to change cmucl to be able to do this. Needless to say we already have this, after several years of hard effort by multiple people, it's just called sbcl.

So in the end the 'everybody uses C' camp won and cmucl on Debian will die a quiet death. It's a sad end for a system hand-patched from PDP10's to modern CPU's over the coarse of almost 30 years...

After some consideration I must conclude that the state of the Common Lisp packages in Debian is becoming unreasonable. One of the goals of forming the pkg-common-lisp team was that I would not be a bottleneck, as RL is inflicting more and more damage to my 'Debian playtime'.

Now that Luca left I'm basically the only 'active' (for very small values of active) DD/DM left. (no hard feeling towards anybody, just loads of thanks for the work they did)

I see two alternatives:

• other people get involved, investigating bugs and sending git/darcs/whatever format patches.


• we go low impact and remove common-lisp-controller and all Common Lisp libraries, and I/we only package the lisp implementations (clisp, ecl, sbcl, cmucl and perhaps ccl) without any special changes

I don't expect the first alternative to be realistic, so unless proven wrong I'll RFA/RM all the libraries/clc on the 5th of September.

This year I managed to go to fosdem every day, even at the beer event. Not that I attended many talks: I was quite busy getting the network to work. We got wireless in almost all locations in the end. Setting up and fixing the problems took most of Saturday. On Sunday we added the final 'experimental' room via a wireless bridge link across the square, with the beam over the heads of the people in the queue for Belgian fries.

In the end it all worked and we had only a few configuration and many cable problems. I must say it was more for to 'work' at fosdem then to just be there. May thanks to Jerome Paquay who actually arranged to lend the equipment from our employer (Cisco) and  to configure it. Thanks for AY for ... well being AY.

Next year n-mode? serious uplinks?

http://kuix.de/sslhazard/sslhazard.php

Yes, I browse to billions of self-signed https sites every day so I needed this...

My wife has a laptop running Vista because she wanted to try out the operating system before having to decide on using it at work.

I called her various names because of it, but that didn't help :-).

So we have this setup with an SMC wireless router/AP talking to a Cisco 837 router that does the internet part. Upstairs we have a 'server' that is connected via Powerline IP-over-power, downstairs we have the Dreambox that is connected via a normal Cat5 connection.

In the last few days my wife complained that it was very slow to download media from Frost. Working at TAC having a network problem at home is almost a personal offence :-) so I decide to take a look and I find using iperf the following speeds:

frost (debian) --cat5--> sharrow (debian): 35 Mbit/sec
frost (debian) ---WL-cat5-> sharrow (debian): 18 Mbit/sec
sharrow (debian) ---WL-cat5-> frost (debian): 18 Mbit/sec
sharrow (debian) --cat5---> frost (debian): 35 Mbit/sec
frost (debian) ---WL---> martha-jones (vista): 0.2 Mbit/sec
sharrow (debian) ---WL---> martha-jones (vista): 12 Mbit/sec
sharrow (debian) ---cat5-SMC-WL--> martha-jones (vista): 6 Mbit/sec
martha-jones (vista) --WL-cat5-> frost (debian): 18 Mbit/sec
martha-jones (vista) --WL--> sharrow (debian): 18 Mbit/sec
martha-jones (vista) --WL-cat5-> sharrow (debian): 18 Mbit/sec

This made no sense at all. The speed halved going from a WL->WL to a WL->cat5 connection but only in one direction!

So having isolated the problem to the Vista machine I started looking round and I found a note saying that running netsh interface tcp set global autotuninglevel=disabled in an 'Administrator' cmd window will fix the problem.

Now I'm very weary of changing the TCP/IP options of the operating system. In most cases the 'tips' you see flying round the internet have no meaning at all and sometimes make the situation worse rather then better.

However I did find this on a Microsoft Technet site.... Hmm

So in the end I try it and modify the setting, disconnect and reconnect to the wireless and:

frost (debian) ---WL---> martha-jones (vista): 18 Mbit/sec
sharrow (debian) ---WL---> martha-jones (vista): 18 Mbit/sec
sharrow (debian) ---cat5-SMC-WL--> martha-jones (vista): 18 Mbit/sec

Aah, finally I could tune Vista so that it has the same speed as an untuned Debian machine. I only took me 2 evenings worth of work...

After upgrading to 2.6.26 I could not associate with my AP anymore. After searching I noticed that the amount of channels reported by iwlist wlan0 channel had changed. And the channel that my AP was using (13) just disappeared.

I openeded a bug with the iwl people and the end result is: in 2.6.25 the card selected the region for the wireless, in 2.6.26 the cfg80211 system is doing so and the default is 'US'.

So if you are in Europe you need to add a file /etc/modprobe.d/cfg80211-region with as contents:

options cfg80211 ieee80211_regdom=EU