I always forget how to use SSH agent key forwarding when using Mosh over to a server.

I mosh to a server and can’t SSH to places:

$ mosh sonar.local
roadmr@sonar:~$ ssh bazaar.launchpad.net
roadmr@bazaar.launchpad.net: Permission denied (publickey).

Run the SSH agent, then export the variables it spits out:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-tW6qDmkDeLn2/agent.1744897; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1744898; export SSH_AGENT_PID;
echo Agent pid 1744898;
$ SSH_AUTH_SOCK=/tmp/ssh-tW6qDmkDeLn2/agent.1744897; export SSH_AUTH_SOCK;
$ SSH_AGENT_PID=1744898; export SSH_AGENT_PID;

One can also just source that:

$ eval $(ssh-agent -s)
Agent pid 1234141

Next, add your keys:

$ ssh-add ~/.ssh/id_rsa.something
Identity added: /home/roadmr/.ssh/id_rsa.something (/home/roadmr/.ssh/id_rsa.something)

And now SSH should work using key authentication.

$ ssh bazaar.launchpad.net
X11 forwarding request failed on channel 0
No shells on this server.
Connection to bazaar.launchpad.net closed.
# The above is successful, the server did accept the connection \o/

I don’t even know/understand how this works :)

If you do any kind of support or deal with customers in any way, it’s likely that 80% of incoming requests can be served by sending a canned reply about one of a handful of common issues.

I keep my canned replies in a specific directory, copy them to the clipboard using xclip and then paste them in whichever web-based ticketing system the request comes from.

For this I used to rely on CTRL-R completion using fzf, but that’s becoming kind of unwieldy; so instead, I crafted an fzf-powered oneliner that gives me a responses command. I run that and I get a list of all the canned responses in the directory with auto-completion as per fzf, and also a nice preview window so I can ensure the text contains what I need to send. On pressing ENTER, this is put in the clipboard courtesy of xclip ready to be pasted.

function responses(){
    xclip -selection c $(find ~/Documents/w/responses -type f | fzf --preview-window='up:40%' --preview 'cat {}')
}

The above goes in ~/.bashrc.

In an email thread with some colleagues, one of them mentioned that they had to force their laptop to use “deep” sleep instead of “s2idle”. This got me thinking - I’ve had the impression that my XPS13 sometimes doesn’t really suspend, and/or wakes up in the middle of the night, because the battery capacity sometimes is lower than it should be after being suspended overnight (going to sleep with 100% battery and having about 70% the morning afeter).

So I quickly looked up “s2idle” and landed here.

From here it looks like indeed s2idle is not really suspend-suspend and the system can wake up of its own accord according to unclear rules (or maybe they are clear, but I don’t care, I want the system to go to full sleep and only wake up when I open the lid or something similar). And it seems the way to get it to real deep-sleep is to write “deep” into /sys/power/mem_sleep. It further mentions that indeed s2idle is the default (which I confirmed by checking the above file), but it can be overridden by setting mem_sleep_default in the kernel command line.

It’s been a while since I last had to muck with GRUB configuration…

Just for kicks I also looked up mem_sleep_default and lo and behold, came upon a thread for the XPS 13 9310 (exactly the one I have).

Most of us have wanted, at some time or another, to share an entire “session” on the terminal. I mean showing a log of the commands we typed, their output, and so on, to illustrate a procedure or clarify a concept.

The “script” command has long been a tool of choice for this. To use it, just type:

script

this will seem to start a new shell process and start recording everything you type and everything that other commands output in response. To stop recording, just type “exit”. A file called typescript will be created with your session. If you want, you can call script with a parameter (script your-file.log) to log to that file instead.

A newer implementation of the concept is ttyrec. It behaves mostly the same as script, but instead of producing openable text files, it logs keystrokes and timing information. You need to play these back using ttyplay, but the result is pretty amazing because you can see the keystrokes being played back as they were typed. You can also instruct ttyplay to just dump the session to a plain text file, which mimics script’s behavior.

Finally, to take this concept one step further, have a look at showterm, which does essentially the same as ttyrec but automatically saves and uploads the session to a website for you to share with people. Think of it as an interactive pastebin.

Many of the on-line instructions and tutorials are quite complicated. Why? It was easy for me:

sudo apt-get install sbuild

To build a virtual machine:

mk-sbuild --distro=ubuntu --arch=i386 precise

this will create a schroot in /var/lib/schroots/precise-i386. Note how it appends the architecture to the schroot name. Also note that the first time you run mk-sbuild, it’ll show you a configuration file and configure your environment. I didn’t change anything in the config file, I used it “as it was”. When it prompts you to log out, do it, otherwise things won’t work.

OK now you want to build a package using your chroot with sbuild:

sbuild -A -d precise package.dsc

This will build the package on precise for ALL available architectures. Note that -d is just “precise”; the -A flag will tell sbuild to build architecture: any packages for all available architectures (so if you have amd64 and i386 chroots, it’ll do the right thing and build two packages).

If you want to build arch-specific packages:

sbuild  -d precise-i386 package.dsc

This will magically build for the given architecture (i386). Note that arch: any packages will also be built.

You can also specify the arch as a parameter (but then you have to leave it out of the -d name):

sbuild  -d precise --arch=i386 package.dsc

This will not work:

sbuild  -d precise-i386 --arch=i386 package.dsc

I remember an easier time when all keyboards had the same layout (C-64, anyone?) and if you wanted to type special characters you had to resort to arcane command sequences, if they were at all possible.

My, how times have changed.

My first PC compatible had a spanish keyboard, and you could very simplistically tell the OS (MS-DOS) about your keyboard layout. For a while this worked pretty well. Then someone decided that Latin America was so different from Spain, that we needed our very own keyboard layout; this layout just moves stuff around needlessly, destroying many years of experience for those of us who were accustomed to the spanish keyboard. I understand removing the ç as it’s not used in Latin America, but why move all the rest of the stuff around?

So basically I got used to the spanish keyboard which has worked well in all kinds of OSes, from MS-DOS to Windows, OS/2 and yes, Linux. While the Latin American layout was such a pariah that, at some point, it got overwritten by the Latvian keyboard (la), so when doing a system upgrade, all of a sudden your keyboard was in latvian, and you had to select “latam” for Latin America.

Eventually I happened to get a laptop with a Canadian French keyboard. Luckily, this is not the dreaded french AZERTY keyboard, but basically an english keyboard layout with most symbol keys mapped very strangely. So if you want to type the basic alphabet you’re OK, like you’d be with an english keyboard, but things start getting weird when you need to create special characters or compose accents, cedillas and stuff like that. This was so different from any other layout I’ve used, that I was basically freaking out. I could just ignore the red characters on my keyboard, and/or use it as just an english keyboard, but I routinely need to compose text in spanish and in french, so how would I go about doing this?

And no, the ages-old trick of memorizing ASCII codes for special characters doesn’t cut it: for one, it’s unreliable on Linux (especially on graphical mode), and for another, it’s just primitive! I used to chuckle at all the people I’ve seen through the years who had a nice “cheat sheet” glued to their desktop with ASCII codes for frequently-used accented characters, as opposed to taking 15 minutes to correctly configure their keyboards to do this natively.

So anyway, what I came across while checking out the available keyboard maps under Linux and trying to figure out how to type stuff on the Canadian keyboard, was this wonder of wonders, the US International with AltGr Dead Keys layout.

Basically, it takes the right Alt key (labeled AltGr on my keyboard, a monstrosity I was already used to from the LatinAmerican and spanish keyboards) and uses it to “compose” or “deadkey” stuff (dead keys are like accents, for instance, where you press the accent key and then the next letter you type will be accented). In combination with ~, “, ‘ and `, this enables me to type nearly all accented characters with relative ease.

Also, I can use AltGr+vowel to type acute-accented vowels (áéíóú), and AltGr+n for ñ.

Grave accents (è) and tilded letters (ã) can be composed by AltGr+accent (use ` for grave, ~ for tilde), and then the letter you want to type.

What I like about Linux’s keyboard selection thingy is that you can see an actual layout map. Thus, even if my keyboard doesn’t have the characters stenciled in, I can take a quick peek and see where stuff I need might be.

Thus I can do things like use ç or €, all with a minimum of fuss. Also more complicated stuff like ï œ ø is still just one AltGr+key away. All this while preserving a layout that’s very familiar to everyone (english), and where most strange characters using while programming {}][\|~ are also much easier to use than on the spanish keyboard I was used to (it needs AltGr for all sorts of braces and piping, which makes it very painful on my hands).

So there you have it, if you see yourself wrestling with choosing a good physical keyboard layout *and* making it work on your OS, stop pulling your hair out, get an english-layout keyboard and use US International with AltGr Dead Keys!

It’s long been argued that peripheral support in Linux is far inferior to that under Windows, and that this has been a factor for Windows’ dominance in the desktop. More and more, the myth that Windows has any kind of technical superiority leaves place to the fact that marketing, and being bundled with nearly every PC sold worldwide, are Windows’ only keys to its widespread adoption. And here’s a story to prove that point.

I bought a printer (HP Photosmart C4780). It’s one of those cheap, $50 numbers that eat through ink like crazy. So I come home, wondering if I’ll have to install 500 MB of crap as included in the bundled CD to get the printer to work with my Mac at home.

As is usually the case with the Mac, I just plugged it in and it worked, both the printer and the scanner, without a hitch or problem.

I then proceeded to do the same on a freshly installed Ubuntu 10.10 laptop. Same story, the printer just worked, and Ubuntu even recognized it when being plugged in, no need to install drivers or anything.

Now, on Windows the printer wouldn’t have worked at all without installing a boatload of crap, HP is notoriously bloaty when it comes to their bundled software.

The usual wisdom is that hardware manufacturers care more about Windows, and ship all their hardware with drivers and stuff to make it work. It would seem, then, that the burden is on Apple and Linux distributions to provide drivers and support to most hardware. It would seem like a daunting task. But they do it, and the end result is that Mac OS and most Linux distros include drivers for everything, right out of the box. This puts them a step ahead of Windows, when it comes to ease of use, at the cost of maybe a slight bloat. Still, my Ubuntu installation is much leaner than the 16-GB behemoth that is Windows 7.

So there you have it, the myth of better hardware support on Windows, finally debunked.

Now, if I could only get the braindead wireless support on the HP printer to work…