The easy answer is “have the user run krfb inside the session first”. But what if you are the user, and you're already remote from the host by the time you remember you needed to do that?

You need to have configured krfb with a remote control password and any other relevant settings, first. See below, but typically you've already done this at some point, so you can move straight to the important part:

ssh you@yourserver
DISPLAY=:0.0 krfb --nodialog

Then try to connect using krdc, or your VNC viewer of choice.

What if you don't have the password, etc., configured? Then:

ssh -X you@yourserver
krfb

This will display the window locally. Configure and close. This mode of operation doesn't work for actually showing the remote session, evidently because the X session forwarded though SSH is somehow a new/separate session. The key to showing the remote session is passing that DISPLAY environment variable.

Other thoughts: Have a slow network? Disable key repeat, or it might stutter. Also, sshuttle is very handy if you have limited port forwarding (but it won't help the network speed situation).

Read this post

If you're like me, you might be using git-svn to connect to centralized SVN repositories (e.g., at the workplace) while keeping many of the powerful features of git. Sometimes you might be working in a local feature branch that is linked to a remote branch, and do a git svn rebase to grab updates from the SVN server. This command only fetches from the corresponding server branch. But, if an SVN merge, say from trunk, had happened on that branch at the server, then git-svn needs the corresponding local master branch to be up-to-date to notice that it was the parent of that merge. If you hadn't fetched from master recently, you lose the merge tree. Oops.

Before the rebase it would've been better to use git svn fetch --all (or it ought to have been, assuming git-svn fetches revisions in order once for all branches). But you might forget to do that. If that's where you find yourself, it is possible to recover. In the feature branch, use git svn reset -r{REV} -p, replacing {REV} with the revision number of the SVN merge which git-svn failed to assign a parent. Then do git svn fetch --all before [...]

Read this post

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

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