I've started using my kinesis keyboard with my laptop a lot during the workday, but not the rest of the time, which means my USB keyboard is being plugged and unplugged often. I prefer to have a lot of keys remapped on the kinesys, So I was having an annoying time having to run xmodmap (possibly without the benefit of having Mod4 to get the window manager to give me a shell) to set these keys.

I survived about two weeks before this bugged me enough to figure out what could be done to solve this. I had solved it once before by dropping a magically crafted file into /etc/hal/fdi/policy, but that system is long gone.

Luckily it looks like thanks (at least in part) to Martin Pitt, udev has a keymap facility for handling this type of scenario.

/usr/share/doc/udev/README.keymap.txt.gz has a bunch of good hints that got me started.

$ /lib/udev/findkeyboards
USB keyboard: input/event2
AT keyboard: input/event0

Finds my keyboard devices. I'm interested in the USB connected keyboard. So I run:

/lib/udev/keymap -i input/event2

To discover scan codes my keyboard generates for the keys I want to remap. here #654928 got me, the trick is to issue the above command from the laptop keyboard, so that the terminal you launched keymap in doesn't get wonky because it never got the key-release event from the enter key.

When I hit keys on my external keyboard now, I get stuff like:

scan code: 0x7004A   key code: home
scan code: 0x700E7   key code: rightctrl

They key codes coming out match what is printed on the keycaps. From here I generate a file matching files in /lib/udev/keymaps, but change the keycodes to the keycodes I want to remap to, ending up with:

0x7004A leftmeta 
0x700E7 rightalt

This file goes into /lib/udev/keymaps/kinesis-stew. It appears the things like leftmeta/rightalt which are valid come from /usr/include/linux/input.h. It also seems to be valid to put hex there, but I didn't find a good way to figure out what hex codes go with which key codes.

Then I look for the VendorID/DeviceID by looking in the output of "udevadm info --export-db" for input/event2 and find:

ID_VENDOR_ID=05f3
ID_MODEL_ID=0007

So now I'm ready to create my udev rule (which I put into /etc/udev/rules.d/99-stew-keymap.rules

ATTRS{idVendor}=="05f3", ATTRS{idProduct}=="0007", RUN+="keymap $name kinesis-stew"

And now everything seems to be good. I can plug and unplug my external keyboard without having to run xmodmap to get the keybindings I want, and the keybindings for the built-in laptop keyboard are not disturbed.

Well, when I got an invite to try G+, I decided to make my first foray into social networking sites since friendster. It was mildly interesting while it lasted, however it seems that it is over for me now.

I tried to use the name "Mike (stew) O'Connor" as I do on my gpg key. This caused my accounted to get flagged as violating their "real names" policy. I can't help but to feel a little offended that they think they know what my name is better than I do. I have a bit of a unique situation with my name. Pretty much NOBODY calls me "Mike" or "Michael" save a few people from my childhood. Its been this way for more than half of my life. My wife only ever has called me "stew". My two year old knows my name is "stew" but doesn't know my name is also "Mike". If I meet somebody new, I always introduce myself as "stew". All my clients call me stew...

The instructions on google plus tell you "To help fight spam and prevent fake profiles, use the name your friends, family or co-workers usually call you.", So when my account was initially flagged. I tried changing my name to "Stew O'Connor". My account was "pending review" and I was still able to post and reply and the like. After review, my account was suspended, some of my privacy settings were changed, and I cannot change them back.

Out of the 60 or so people that added me on G+, only one of them should ever be referring to me as "Mike". When someone calls me Mike that isn't one of the handful of people that "should" be calling me "Mike", my brain immediately puts them in the "oh, you don't know me very well" category. Oh well, Google, amazingly, you don't know me very well. After explaining to someone "oh, no you really should call me stew like everyone else", you say "No, I'd rather just not talk to you", now you are just being a jerk.

Now I guess I have a retort to people that use the phrase which I find so annoying: "GIYF".

Update: I appealed to change my name to Stew O'Connor which was denied, then appealed to change my name to Mike O'Connor which was also denied. I guess I was supposed to use "Michael" or something? Being denied "Mike", I deleted my suspeneded G+ account, feeling extra flouncy, chnaged by default search engine to duckduckgo.com.

Today I was made aware of bug #607839, and it makes me sad. I think its a great example about how trademarks and free software do not coexist well together. This bug started out as a question of the copyright license of a file, but quickly turned into a discussion about the GNOME™ [0] trademark, and the GNOME™ Foundation Trademark Usage Guidelines for Third Parties

I believe that the GNOME™ project would be standing on solid legal ground if they wanted to actually try to aggressively protect their trademark. It is easy for me to find hundreds of places we use their mark in ways that are expressly forbidden by their trademark license. Here are some examples:

grep -i "gnome's" /var/lib/dpkg/available  # many package descriptions invalidly using a possessive
grep -i "gnome[^™]" /var/lib/dpkg/availabe # returns nothing, trademark symbol is required

Probably to be in strict compliance, we would need to allow uppercase letters in package names. (I doubt this would happen, especially not for a reason like this).

I am sure that a lawyer would tell us that the safest legal place for Debian would be to abandon all use of their marks. This would unfortunately be a herculean effort on Debian's part; we'd have to rename tons of packages, create and maintain tons of patches, create new logos, etc. And, I believe it would have the unfortunate side-effect of having a negative impact on both projects from a publicity standpoint. As with the firefox/iceweasel situation, the company trying to protect its trademark looks like a bully, and Debian looks like out-of-touch zealots. From the tone of the conversation in the bug report, I do not believe that this is something that the GNOME Foundation would force on us, and I certainly don't believe it would be an outcome they would hope for.

They could give us written permission to use their marks in the ways we are already using them, however, lots of people would point at DFSG#8, and this would fail the 'tentacles of evil' test. (We are, of course, already under the grasp of these tentacles, as their current trademark license is subject to change) Better for us would be if they modified their trademark license agreement in order to allow our current usages of their mark. I feel that this quite unlikely to happen. It would certainly weaken their hold on the mark.

Trying to apply the DFSG in these situations also doesn't work as well as it should. The DFSG is written with copyrights in mind and not patents and trademarks. This feels to me similar to situations we have with patent encumbered software which is under a perfectly free license. We can distribute the software without fear of a claim that we are violating copyrights, but the software is still not perfectly free since as I user, my rights to use and distribute the software might be severely limited from a legal standpoint. Also by Debian choosing to distribute software which has these kinds of potential problems, we might be putting a legal liability on members of the project and people that run mirrors for us.

Of course, to add to the conflict I feel, Debian has its own trademarks, which it is poor at enforcing. On one hand, its bad for all the reasons that this situation is bad. On the other hand I sometimes wish that Debian did a better job of protecting its own trademark. It's clear from how many people show up in #debian expecting support for linuxmint or aptosid claiming "linux mint debian edition IS Debian, it says so on linuxmint.org" that we have allowed our mark to be diluted.

NOTE: I became aware of this bug because of Zack CCing the FTP team. I serve on this team as an assistant, however, My comments here come from me personally without any discussion with other members of FTP team and should not be taken as any kind of official word from the FTP team.

[0] I suddently feel compelled to mention that The GNOME name is a registered trademark of GNOME Foundation in the United States or other countries.

Erich Schubert's blog post reminded me that I've been meaning to writeup a post detailing how I'm keeping parts of my $HOME in git repositories.

My goal has been to keep my home directory in a version control system effectively. I have a number of constraints however. I want the system to be modular. I don't always need X related config files in my home directory. Sometimes I want just my zsh related files and my emacs related files. I have multiple machines I check email from, and on those want to keep my notmuch/offlineimap files in sync, but I don't need these on every machine I'm on, expecially since those configurations have more sensitive data. I played around with laysvn for a while, but it never really seemed comfortable. I more recently discovered that madduck had started a "vcs-home" website and mailing list, talking about doing what I'm trying to do.

I'm now going with madduck's idea of using git with detached work trees, so that I can have multiple git repositories all using $HOME as their $GIT_WORK_TREE. I have a script inspired by his vcsh script that will create a subshell where the GIT_DIR, GIT_WORK_TREE variables are set for me. I can do my git operations related to just one git repository in that shell, while still operating directly on my config files in $HOME, and avoiding any kind of nasty symlinking or hardlinking. Since I am usually using my script to allow me to quickly "move in" to a new host, I named my script "movein". It can be found here. Here's how I'll typically use it:

    stew@guppy:~$ movein init
    git server hostname? git.vireo.org
    path to remote repositories? [~/git] 
    Local repository directory? [~/.movein] 
    Location of .mrconfig file? [~/.mrconfig] 
    stew@guppy:~$ 

This is just run once. It asks me questions about how to setup the 'movein' environment. Now I should have a .moveinrc storing the answers I gave above, I have a stub of a .mrconfig, and an empty .movein directory. Next thing to do is to add some of my repositories. The one I typically add on all machines is my "shell" repository. It has a .bashrc/.zshrc, an .alias that both source and other zsh goodies I'll generally wish to be around:

    stew@guppy:~$ ls .zshrc
    ls: cannot access .zshrc: No such file or directory
    stew@guppy:~$ movein add shell
    Initialized empty Git repository in /home/stew/.movein/shell.git/
    remote: Counting objects: 42, done.
    remote: Compressing objects: 100% (39/39), done.
    remote: Total 42 (delta 18), reused 0 (delta 0)
    Unpacking objects: 100% (42/42), done.
    From ssh://git.vireo.org//home/stew/git/shell
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .zshrc
    .zshrc

So what happened here is that the ssh://git.vireo.org/~/git/shell.git repository was cloned with GIT_WORK_TREE=~ and GIT_DIR=.movein/shell.git. My .zshrc (along with a bunch of other files) has appeared. Next perhaps I'll add my emacs config files:

    stew@guppy:~$ movein add emacs       
    Initialized empty Git repository in /home/stew/.movein/emacs.git/
    remote: Counting objects: 77, done.
    remote: Compressing objects: 100% (63/63), done.
    remote: Total 77 (delta 10), reused 0 (delta 0)
    Unpacking objects: 100% (77/77), done.
    From ssh://git.vireo.org//home/stew/git/emacs
     * [new branch]      emacs21    -> origin/emacs21
     * [new branch]      master     -> origin/master
    stew@guppy:~$ ls .emacs
    .emacs
    stew@guppy:~$ 

My remote repositry has a master branch, but also has an emacs21 branch, which I can use when checking out on older machines which don't yet have newer versions of emacs.

Let's say I have made changes to my .zshrc file, and I want to check them in. Since we are working with detached work trees, git can't immediately help us:

    stew@guppy:~$ git status
    fatal: Not a git repository (or any of the parent directories): .git

The movein script allows me to "login" to one of the repositories. It will create a subshell with GIT_WORK_TREE and GIT_DIR set. In that subshell, git operations operate as one might expect:

    stew@guppy:~ $ movein login shell
    stew@guppy:~ (shell:master>*) $ echo >> .zshrc
    stew@guppy:~ (shell:master>*) $ git add .zshrc                                       
    stew@guppy:~ (shell:master>*) $ git commit -m "adding a newline to the end of .zshrc"
    [master 81b7311] adding a newline to the end of .zshrc
     1 files changed, 1 insertions(+), 0 deletions(-)
    stew@guppy:~ (shell:master>*) $ git push
    Counting objects: 8, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (6/6), done.
    Writing objects: 100% (6/6), 546 bytes, done.
    Total 6 (delta 4), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/shell.git
       d24bf2d..81b7311  master -> master
    stew@guppy:~ (shell:master*) $ exit
    stew@guppy:~ $ 

If I want to create a brand new repository from files in my home directory. I can:

    stew@guppy:~ $ touch methere
    stew@guppy:~ $ touch mealsothere
    stew@guppy:~ $ movein new oohlala methere mealsothere
    Initialized empty Git repository in /home/stew/git/oohlala.git/
    Initialized empty Git repository in /home/stew/.movein/oohlala.git/
    [master (root-commit) 7abe5ba] initial checkin
     0 files changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 mealsothere
     create mode 100644 methere
    Counting objects: 3, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 224 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To ssh://git.vireo.org//home/stew/git/oohlala.git
     * [new branch]      master -> master

Above, the command movein new oohlala methere mealsothere says "create a new repository containing two files: methere, mealsothere". A bare repository is created on the remote machine, a repository is created in the .movein directory, the files are committed, and the new commit is pushed to the remote repository. New on some other machine, I could run movein add oohlala to get these two new files.

The movein script maintains a .mrconfig file, so that joeyh's mr tool can be used to manage the repositories in bulk. Commands like "mr update", "mr commit", "mr push" will act on all the known repositories. Here's an example:

    stew@guppy:~ $ cat .mrconfig
    [DEFAULT]
    include = cat /usr/share/mr/git-fake-bare

    [/home/stew/.movein/emacs.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/emacs.git' 'emacs.git' '../../'

    [/home/stew/.movein/shell.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/shell.git' 'shell.git' '../../'

    [/home/stew/.movein/oohlala.git]
    checkout = git_fake_bare_checkout 'ssh://git.vireo.org//home/stew/git/oohlala.git' 'oohlala.git' '../../'

    stew@guppy:~ $ mr update
    mr update: /home/stew//home/stew/.movein/emacs.git
    From ssh://git.vireo.org//home/stew/git/emacs
     * branch            master     -> FETCH_HEAD
    Already up-to-date.

    mr update: /home/stew//home/stew/.movein/oohlala.git
    From ssh://git.vireo.org//home/stew/git/oohlala
     * branch            master     -> FETCH_HEAD
    Already up-to-date.

    mr update: /home/stew//home/stew/.movein/shell.git
    From ssh://git.vireo.org//home/stew/git/shell
     * branch            master     -> FETCH_HEAD
    Already up-to-date.

    mr update: finished (3 ok)
    stew@guppy:~ $ mr update        

There are still issues I'd like to address. The big one in my mind is that there is no .gitignore. So when you "movein login somerepository" then run "git status", It tells you about hundreds of untracked files in your home directory. Ideally, I just want to know about the files which are already associated with the repository I'm logged into.

Update: movein has its own page now.