Multi-booting is a widely-used practice that enables a user to select the OS best suited for their current task. For example, I dual-boot Windows and Linux on my laptop which allows me to get the best of both worlds on the same machine.

I’ve encountered a minor pain point in this setup however, largely due to the way I tend to use my machine: once I boot a particular OS I continue to use that same OS repeatedly and expect reboots/shutdown/startup to continue to use the last OS I booted. This is especially true of reboots, for example after installing system updates.

Traditionally I addressed this by setting the default boot to my most-frequently-used OS, but really that is just optimizing for the common case and not solving the issue. Additionally, I’ve recently started using Windows more and am annoyed having to remind my machine what OS I’m using.

So, today I sat down and put together a simple little utility to fix this properly once and for all.

The freenode IRC network has for a long time supported connecting and automatic identification using SASL.

Recently, the freenode network deprecated the commonly used SASL mechanism DH-BLOWFISH due to security concerns, causing my IRC client (irssi) to no longer be able to authenticate.

Unfortunately, while scripts and guides describing using irssi with DH-BLOWFISH are plentiful, it seems the steps required to use the new preferred ECDSA-NIST256P-CHALLENGE method are not yet documented.

Read on for a step-by-step walk-through of configuring irssi to use SASL with freenode in 2015.

My residential internet experience has always been poor, so when I started observing bizarre network behavior a few months back I attributed it to upstream problems and wrote it off with a sigh. The issue persisted however, so over the winter break I decided to sit down and tackle it once and for all.

Tracking down the source of the issue was an interesting adventure, and ultimately the problem was in the last place I thought to check: a pair of TEG-S80g unmanaged gigabit switches made by TRENDnet.

Do not buy! :)

Details follow.

In all varieties of C/C++, pointer arithmetic is undefined if it overflows. That is to say the following example:

void invalid(char *p) {
  char *q = p + 1;
  printf("%p\n", p - (uintptr_t)q);
}

invokes undefined behavior as it causes the pointer value to wraparound to the equivalent of -sizeof(char), which is 0xffffffffffffffff on my 64bit system.

Unlike integer overflows which can be dangerous or benign regardless of intention (ICSE12), pointer overflows are very unlikely to be intentional and may be the source of a more serious bug resulting in incorrect behavior or program crashing.

While working on hacking the FreeBSD kernel for a research project, I of course have crashed things many times. Hooray for VM’s.

However, this latest time I’ve managed to really mess things up. Instead of some esoteric message in the logs, the result was the following being written to the console:

Nonsense Kernel console output

Hopefully those of you who’ve hacked on kernels previously will appreciate the “wut” moment you get when your screen looks like this instead of acting as expected :).