Here's a subtle one. Assume you have the appropriate “using System.Collections.Generic;” clause included somewhere up above. Can you spot what's wrong with this code?

interface ITestInterface
{
}

class TestClass<T>
    where T : ITestInterface
{
    public void TestMethod()
    {
        IReadOnlyList<T> x = null;
        IReadOnlyList<ITestInterface> y = x;
    }
}

Seems reasonable, right? An IReadOnlyList is covariant in its stored type, so given that T is constrained to be an ITestInterface, assigning such a list of T to a list of ITestInterface should be fine. And yet, compiling this code will fail at “y = x”, being unable to implicitly convert the types.

After some hair-pulling, I eventually worked out that the solution is to add “class” to the constraints on T. It would seem that, otherwise, the compiler will assume that the generic type T will not have any kind of inheritance for which covariance will be relevant. So it doesn't consider that, and the cast fails.

Read this post

The default configuration of the X server in Debian keeps a log of all the console output of the programs a user runs from their X session. It also keeps this log indefinitely. This is quite clearly a design mistake, because even ignoring badly behaved programs (those which are needlessly noisy are indisputably buggy), enough legitimate errors will eventually eat your disk. Plus the unjustifiable assumption that all programs out in the wild will be well-behaved, which is a nice hope but contrary to reality.

Sadly, this behaviour is also an ancient bug that has been, it would seem, forgotten about.

Anyway, here's a relatively simple method to fix that. As root, edit /etc/X11/Xsession. Just below the ERRFILE=$HOME/.xsession-errors line, add this:

ERRFILEOLD="$ERRFILE".old

if [ -f "$ERRFILE" ]; then
set +e
mv -f "$ERRFILE" "$ERRFILEOLD" 2> /dev/null
set -e
fi

Each time the user logs in, the old .xsession-errors log file will be moved to .xsession-errors.old (overwriting anything already with that name), and a new one created. Thus it ensures that the file doesn't grow indefinitely, so long as the user logs out and back in at some point.

Read this post

Light can be used to encode information in a variety of ways. Polarization, for example: a ‘0’ bit could be represented by a pulse of horizontally polarized light, and a ‘1’ bit could be vertically polarized. This generally works well for transmissions over free-space. Also, by allowing superposition states and reducing the intensity to single-photon levels, one can start to access interesting quantum protocols such as quantum key distribution (QKD). You can do this with other encodings, too—“time bin”, for example, where you encode information in the arrival time, early or late, relative to a reference. But because of the way the superposition state (that is, the early “and” late state) is measured, it doesn't generally work well over air because of turbulence.

A recently discovered enhancement of the measurement device by my colleagues intrinsically bypasses the turbulence problem, and in this paper, we couple this improved apparatus with a QKD system to demonstrate a real quantum protocol with time-bin encoded light transmitted over long-distance (1.2 km) free space. The approach we take here could in future be used as a bridge between optic fiber (where turbulence isn't an issue) and free-space for quantum protocols.

Read this post

At some point along Debian's journey, rescue and emergency runlevels broke for anyone who has a locked root account and, say, uses sudo exclusively to run administrative commands. See the bug report and a proposed installer patch. This is not an atypical setup—it's a standard option of the Debian installer, and happens to be one I typically use.

To summarise what's going on, the system now prevents root from logging in due to it being a locked account (having no password, it cannot be authenticated), which means that the rescue and emergency runlevels always error and fail to bring up a shell. What bloody good are they, then, right?

Not too long ago things got to the point where the system can be configured to work as expected, again, but certain settings need to be enabled beforehand. This is described below. Note that doing so arguably introduces a security issue, but if you're happy to run Grub with editable boot entries (so that any user could, say, set init=/bin/bash on the kernel command line), then you're unlikely to have any reason to care.

First switch to root using “sudo su -”. Then:

for x in /etc/systemd/system [...]

Read this post

I use KMail and it, like many other popular email clients, sorts messages into threads. It does this based on reference information embedded in the (usually hidden) headers of each message. Of course, sometimes those headers are off. Most commonly this happens because a sender uses a reply-to-all function to send a new message to an existing list of addresses—this new message has a completely different subject from the original (to which it's ostensibly replying), but the sorting at the receiver's email client still considers it part of the old thread because reply-to-all functions add headers referencing the original message, as well as others in the original thread.

Fortunately, KMail has the ability to remove those headers through manually applied filters. The bonus is that, once you do this, the corrected threading will propagate to other email clients—I use K-9 Mail (not related to KMail) on my phone, for example.

First, there are two email headers that are relevant, each serving a different purpose: In-Reply-To, which links to the previous email that the present one is a direct reply to, and References, which lists several emails that are considered part of the thread (according to reply-to-all). For a [...]

Read this post

Some of my personal projects are tracked using private git repositories, hosted on this server. I can access these via ssh, but for a while I've had in mind to make at least a couple of them publicly accessible... somehow. After finally getting around to looking into it, this turns out to be deceptively simple using git-daemon (instructions for Debian distros):

1. Install the git-daemon-sysvinit package.
2. Enable the daemon by editing /etc/default/git-daemon. Reboot, or start the git-daemon service by hand.
3. Add a symlink to each git repo you want to make public under /var/lib/git. These will then be accessible via git://<hostname>/git/<linkname>.
4. Ensure the git protocol port (9418) forwards to the server.

Simple! The git protocol is faster than serving over http(s), and the standard configuration ensures that anonymous clients can pull, but not push, which is exactly what I was after.

Over the next little while I'll introduce the couple of projects that I'm opening up for public access.

Read this post