So we did get back from our 10 days trip to Portugal. We started off in Lisbon and stayed for three days in the Alfama area of the city.

Afterwards we rented a car at Televan and drove all the way up to Porto, stopping once in Coimbra. Porto was by far the most fascinating place we ended up in.

Then it was Faro's turn and some bathing in the ocean. We both got (obviously) sunburned and drove back to Lisbon, where we met up with Simone and Paola.

Once, back from Portugal, we took a plane and went to Bern Kastel on the "Mosel" for Volker's and Katja's wedding :

Leaving in a little while for Portugal. We'll be staying in Lisbon for three days, then we'll rent a car and drive up to Porto. After staying in Porto for two days we'll drive all the way down to Gambelas (close to Faro, in the Algarve area). Three days there, and then back to Lisbon and on our way home.

As part of a consultancy job for a client, I was asked to figure out why a Microsoft Project Server installation, would start behaving oddly when accessed from a remote company's site. The M$ consultant, started raving about how there was something wrong with the authentication system (which is based on Samba 3.0.x and which I currently maintain) or that it was probably the Ipsec VPN between the main site and the remote site. I started double-checking the VPN, the samba logs, and pretty much anything else that could possibly have an impact. At a certain point, I excluded pretty much every aspect I was in charge of. The M$ guy, still insisted something is wrong on our VPN, so I decide to set up another one with our office... The server wouldn't work there either. You could log in, start doing stuff, but as soon as you clicked on _Projects _you'd get a blank page instead of the crappy ActiveX-gantt chart you were supposed to get. Then I stumble into this gem from Microsoft:

Latency becomes an issue if you need to move large amounts of data over the WAN connection,




such as when a Project Professional user opens a project. For most organizations, WAN




performance is acceptable if latency does not exceed 30 ms. Regardless of bandwidth, if




your WAN connections have a latency of above 30 ms, you might need to use Terminal Server.

So after a lot of cursing, the bottom line is Microsoft Project Server doesn't work if your network latency is higher than 30ms. This, just to show a tiny pathetic Gantt ActiveX control. I'm sure sniffing all the RPC calls involved would reveal some first-class programming there ;)

Chased down an odd behaviour between ISC Dhcp (3.0.4 in my case) and some Mac OS X clients. You'd see the clients doing a DHCPDISCOVER, receive the DHCPOFFER from the server but no DHCPACK would ever show up in the logs. After some sniffing and some trial and error, we found the culprit:

server-identifier "srv01";

After changing it to:

server-name             "srv01.domain.lcl";

the Mac OS X clients started working again.

Tweaked the excellent udev to create /dev/adb and_ /dev/fb*_, by adding the following lines to /etc/udev/links.conf:

D fb
M fb/0          c 29 0
L fb0           fb/0
M adb           c 56 0

David Bowie - The Rise and Fall of Ziggy Stardust and the Spiders from Mars - Five Years

After way too much procrastination, I finally went ahead and became an FSFE Fellow. I started to look around if I'll be able to use the integrated smart-card reader in my Dell Latitude D810 with the FSFE cryptocard. The specs on Texas Instruments' site aren't really useful for the smartcard part of the PCI6515, so the only way is to reverse engineer the windows drivers. There is already a wiki to collect some info about this chip from Texas Instruments. I quickly cooked up a rough kernel module that probes the PCI Configuration space and registers an interrupt, but to progress on this work I need to look at reverse engineering the windows drivers...