Blog <-

Archive for the ‘fun’ Category

RSS   RSS feed for this category

The user isn't always wrong

Some time ago, my mother bought a new laptop. It came preinstalled with Windows Vista, which proved to be quite the disaster. The laptop wasn't nowhere near fast enough to run it, so I installed Ubuntu on it. This allowed my mom to do everything she needed to do with the laptop, while at the same time making it easy for me to administer the beast.

One day my mom phoned me, and explained about a problem she was having:

"Whenever I move the laptop into the kitchen, it stops working!"

Now my mom is no computer expert, but she picked up Ubuntu quickly and has never needed much hand-holding when it comes to using the laptop. This one, however, sounded to me like one of those situations where the user couldn't possibly be correct. We went through the basic telephone support routine, but she persisted in her observation that somehow the kitchen was responsible for her laptop misery.

Eventually, after deciding the problem couldn't be fixed over the phone, I agreed to come over to my parents house the next evening to take a look at it. With my general moody "a family member's PC needs fixing" attitude and a healthy dose of skepticism ("this is going to be one of those typical the-cable-isn't-plugged-in problems"), I arrived at my parents.

"Okay, let's see if we can't fix this problem", I said, as I powered up the laptop upstairs. Everything worked fine. Picking up the laptop, I moved it downstairs into the living room. No problems whatsoever. Next, the kitchen. And lo and behold:

The laptop crashed almost immediately.

"Coincidence", I thought, and tried it again. And again, as soon as I entered the kitchen, the laptop crashed. I… was… Stunned! I had never encountered a problem like this before. What could possibly make it behave like that?

After pondering this strange problem for a while, I thought "what's the only location-dependent thing in a laptop?", and it dawned on me that it might just be related to the WiFi. I powered up the laptop once again in the living room, completely turned off the WiFi by rmmod-ing the relevant kernel modules, and entered the kitchen. No crash. It kept on working perfectly. Until I turned on the WiFi again.

With the aid of some log files (which I should have checked in the first place, I admit), I quickly found the culprit. The very last thing I saw in the log files just before the computer crashed… an attempt to discover the neighbors WiFi! A wonky WiFi router in combination with buggy drivers cause the laptop to crash, but only when it came in range of said WiFi router. And that happened only in the kitchen!

In the end I disabled automatic WiFi discovery on the laptop, since my mom didn't really take it out of the house anyway, and the problems disappeared. I never encountered a problem like that again, but I did learn one thing though:

No matter how impossible the problem may seem… The user isn't always wrong.


I teleported home one night
With Ron and Sid and Meg.
Ron stole Meggie's heart away
And I got Sidney's leg.

— Douglas Adams, The Restaurant at the End of the Universe.

Rokers zijn sexy (Dutch)

Want laten we eerlijk zijn, rokers hebben humor. Rokers hebben stijl. Rokers zijn sexy motherfuckers. Na het neuken rook je samen bezweet een sigaret in bed. Niet-rokers aaien samen een kat.

Beste.. column.. ooit: Rokers zijn sexy


For fun, I wrote a brainfuck interpreter in Python. Brainfuck is an esoteric (joke) programming language which is Turing-complete (given enough memory) with only 8 op-codes (instructions). It was designed to allow for the smallest possible compiler.

There are already some other Brainfuck implementations in Python, but they are either obfuscated or extremely slow. pyBrainfuck is optimized for speed by pre-caching loops and removing non-brainfuck opcodes.

PyBrainfuck can be used both as a stand-alone Brainfuck interpreter or as a python library. It can read from standard input or from a string (in library mode) and write to standard out or to a string buffer (in library mode).

pyBrainfuck is released under the MIT license. You can directly view the code for the interpreter at the Subversion front-end.


Since me and my housemate have been living in our house for nearly one and a half years now, we thought it was high time for a house warming party! But who to invite? "Well", we thought, "why not invite everybody"?


Friday, 25th of Januari 2008
Party at our place!

The party starts at basically whatever time you'd like to show up. A general guideline would be around 8 o'clock in the evening, but you're more than welcome earlier. We haven't set an end time for the party, so we can keep going all night long if need be.

Who's invited?

Everybody's invited! You can bring your friends, coworkers, your significant others, your mom, whoever you want. We really don't mind. The more, the merrier, we always say.


The party will be held at our house. The address is:

Lloyd Webberhof 56
3543 EH
The Netherlands


Here's the place on Google Maps.

If you're coming in by train, there's a train station (Utrecht Terwijde) quite near our house. Once you disembark from the train, go down the stairs and straight ahead over the old tracks and over the little bridge. Go left, past the bicycle stands, then right (yes, you can walk on that street, no worries). You'll pass a park on your left. Take the first street on the right and immediately go left, in between the houses and the tall ugly building. Take the first street on the right. This is the Lloyd Webberhof. Number 56 is all the way at the end, on the right – just follow the music ;-).

If you're coming in by car: From Amersfoort get on the A28 towards Utrecht. From the A28, get on the A27 towards Den Haag/Breda. Take the exit to the A2 towards Utrecht/Amsterdam. On the A2, take exit 7 'Oog in al'. Take the second street on the right, BEFORE crossing the bridge. You'll go all around and over the highway and will end up at a roundabout. Take a left at the roundabout, then take the first street on the right (passing through a tunnel underneath the railway). Out the tunnel, take a left. Take the fifth street on the right. Take the first left, and keep going until you're almost at the end of the road (which ends in a T-section). Before that T-section, you'll see parking spaces on your right, where you can park your car. On the other side of the house bordering the car park is the Lloyd Webberhof.

Tha booze and tha food

Since we have absolutely no idea how many people are going to show up, it would be a good idea to bring your own booze and food. Naturally we'll have some, but we honestly can't say if it'll be enough. So, rather safe than sorry, right?


If you want to, you can sleep over at our place. There's plenty of room for people to sleep, but you'd be wise to bring your own sleeping gear (airbed, sleeping bag, pillow), since we don't have many spare beds. Also, you'll probably have to share a room with some other people. If this bothers you, bring a tent or something.


Wanna know more? Can't find the house on friday? You can send me email and find out my MSN/ICQ address by going to this page: Contact information. In case you need to call me (cause you can't find the house or whatever), my phone number is: +316********. (Update: Removed after the party for obvious reasons :-P)


No presents please! Unless it's booze for yourself.

Why Ethernet didn't work, the real story

I was just browsing around on Slashdot a bit, and I found an article on the topic of Token Ring Networks.

We all know that back in the day, Token Ring was considered 'better' than Ethernet because Ethernet would start colliding like mad under heavy (60/70% and higher) loads. This was because there was no central authority on who was allowed to send over the wire with Ethernet, so nodes on the network had to duke it out amongst themselves using Carrier Sense Multiple Access with Collision Detection. The more nodes on the network, the more collisions. Token Ring didn't suffer from the same problem, giving higher possible loads on a network.

But this interesting comment on Slashdot claims something else:

In theory, Ethernet on coax should be stable under heavy load. But in the late 1980s and early 1990s, it wasn't, due to defective design of some widely used interface chips. Here's the actual story. See this note by Wes Irish at Xerox PARC [link dead, so not included]

The worst device was the SEEQ 8003 chip, found in some Cisco and SGI devices. Due to an error in the design of its hardware state machine, it would turn on its transmitter for a few nanoseconds in the middle of an interframe gap. This noise caused other machines on the LAN to restart their interframe gap timers and ignore the next packet, if it followed closely enough. This happened even if the SEEQ chip was neither the sender or the receiver of the packets involved. So as soon as you plugged one of these things into a LAN, throughput went down, even if it wasn't doing anything. A network analyzer wouldn't even see the false collision; this was at too low a level.

This was tough to find. Wes Irish worked on the problem by arranging for both ends of Xerox PARC's main coax LAN to terminate in one office. Then he hooked up a LeCroy digital oscilloscope to both ends. Then he tapped into a machine with an Ethernet controller to bring out a signal when the problem was detected and trigger the oscilloscope. Then, when the problem occured, he had a copy of the entire packet as an analog waveform stored in the scope. This could then be printed with a thermal printer and gone over by hand.

Because he had the same signal from both ends of the wire, the wierd SEEQ interference mentioned above appeared time-shifted due to speed of light lag, making it clear that the interference was from a different node than the one that was supposed to be sending. You could measure the time shift and figure out from where on the cable the noise was being inserted. Which he did.

It took some convincing to get manufacturers to admit there was a problem. It helped that Wes was at Xerox PARC, where Ethernet was born. I went up there to see his work, and once I saw the waveforms, I was convinced. There was much faxing of waveform printouts for a few months, and some vendors were rather unhappy, but the problem got fixed.

So that's why.

I'm not completely convinced that is the real reason why Ethernet didn't perform well under high loads back in the day (these days, switches take care of the problem of high levels of collisions on Ethernet networks), but it does make for an interesting read.

It's not a Problem; it's a Challenge!

I finally have a reply to the oft-heard managerial "It's not a Problem; It's a Challenge!":

"ITIL doesn't define 'Challenge'. ITIL only defines incidents and problems". That outta shut them up. :-D

Arrr, me hearties!

'Tis that time o' the year again, me hearties! Yarrr! Now, where's me grog?

AFDB. Keep your mind to yourself

A link related to the previous post: The Aluminum Foil Deflector Beanie.

Thanks Aczid.

No more mosquitos!

For the last year and a half, I've been terrorized by mosquitos. At night they even had to queue up and draw a number before they got a chance to drain my blood. I've tried everything to get rid of them, all to no avail. I kept the windows closed, burnt essence, air-tightly closed off my room when I was sure there where no mosquitos in it, bought expensive electrical anti-bug devices and more. Nothing worked. On 'good' nights, I've killed more than twelve pesky buzzers in two hours.

But now I've found the ultimate solution, and I can't believe I didn't think of this before. I'm now sleeping in this:


No, this is not a joke.