1. Tell me, I can fork the project to richoH to keep the links working for now
2. Fix the link! Just change richoH to richo

First up- homebrew is actually not all that bad. It only took me a weekend to get a workableish environment up with recent versions of everything I need. One thing that irked me to no end though, was lack of support for threading conversations like I used to get in Debian.

After quickly cloning the Debian repo and building it on OSX.. no dice. So evidently it’s some unique combination of the Debian patchset and the correct compile options. This managed to take me 3 days, by the time I worked out the correct options, got it to build with clang, shuffled a patch around to unbreak some inlined functions (No idea how that ever built in the first place, actually..)

The short version though, is that if you want your very own mutt that threads messages, it’s as simple as

brew install --HEAD https://raw.github.com/richo/homebrew/f35164afb848d5fd856233fca69662b55fdf2740/Library/Formula/mutt.rb

Which pulls from the psych0tik clone of mutt (I’m slowly moving all of the packages available in the psych0tik apt repo to the psych0tik GH account)

Ninja edit:

It’s more than likely that you want the latest version of this brew which does a lot more to make sure it’ll actually work. I suggest fetching the features/upstream_mutt branch from github.com/richo/homebrew

We knew immediately that we didn’t want to use basic auth, obviously preferring the oauth library which is significantly more secure, but upstream requiring a callback uri is very impractical in the case that you don’t have one available.

The solution in the end wasn’t as complex as I thought it would be. Basically, I wrote a webservice that the client connects to, which gives it a unique URL. We then use the URL we’re given as a redirect URL.

At this stage it’s realistically only sensible to use it as a proof of concept, as it gives you the token in plaintext and doesn’t have SSL.

For version 2 I’d like to export the SSL to the client, and merely relay the encrypted packets. I’d also like to have the whole thing http encapsulated, for now synchronicity complaints (and if we’re honest, the fact that I just wanted the damn thing working) meant that I wrote it with a vaguely flawed thread spawning model and not a lot of protection against DDoS attacks.

If none of this scares you off though, it’s currently running at oauth.psych0tik.net

The procedure is:

Connect on port 2000
recieve your 128 byte callback ID
Send http://oauth.psych0tik.net/callback/[callback ID] as your callback ID to the oauth endpoint
recieve your token from the original connection

Call it a day!

Source is on my github account

The newer of my two Mac Book Pros is a 2011 model, which seems to be a very buggy version of the hardware.  I’ve had two logic boards completely fail, within a few months of getting the device new.  After those were replaced, and continued to fail, the device was deemed a lemon – and replaced in whole.  The new Mac worked fine for almost a year, but is now having issues with the RAM controller, where only the top slot works.

While dealing with these issues, I’ve been to the Apple store a few times.  One of their more obnoxious policies is that repairs cannot be done with out all of the original hardware installed.  So if you’ve upgraded a hard drive, you’ve got to downgrade things.  In my case, they wanted to RMA the entire device, including a hard drive that contained my personal information.

They do offer the service to migrate your files and applications in the store (probably using the same tool that does it on first boot), but if you tend to encrypt your home directory, even with FileVault, it throws off this process (presumably because it cannot access configuration files in your homedir needed to enumerate what to copy.)

This left me with 2 options: tell the Apple Geniuses my password (sort of defeats the purpose of encrypting, eh?), or get the drive from them to suss out backing up on my own.  Needless to say, I went the later route.

I happened to have an extra Mac, a SATA to USB enclosure, and a 3TB external drive on hand to handle and test the copy.  I also pulled in a generic linux box for fdisk and other toos, to do some of the heavy lifting as I don’t particularly like OSX’s disk management tools and I don’t want my drive to end up HFS.  My plan was to make 2 different backups: a copy of the homedir and a dd of the full disk (call me paranoid, but I like being sure I didn’t forget something.)

I immediately ran into issues when I found that fdisk and diskutility don’t play nicely together.  If one partitions the drive, the other can’t read or use it (the same goes for mounting), which is probably a result of the EFI setup used by OSX.  Additionally, in their infinite wisdom, Apple decided that the only truly cross-platform file system they support would be Fat32, which won’t support large files (like a 500G dd.)   As I didn’t want to leave my Mac tethered to some USB drives for 25 hours, this caused a real headache.

Originally, I had a rant here to the effect of ‘Apple|Microsoft – y u no hav better FS support”, but I decided to do a bit of digging to sort that out.  From what I’ve read, OSX doesn’t include support for things like Ext3/Ext4 due to GPL issues and their lack of desire to publish code.  As far as I can tell, Microsoft is simply ignoring filesystems they’ve got no stake in.  Neither of these reasons really help us, but I suppose when running a business you’ve got to prioritize.  In my research efforts, I did come across a particularly good post on adding support via FUSE drivers and the like – lifehacker.

I ended up reformatting the 3TB external drive with diskutil, so that it was usable with my other Mac, and then hooked up the old drive via the USB->SATA converter.  At this point I started looking at the attached hard drive from the old Mac Book Pro, to ensure I could work with everything in the way I expected.  Part of this involved dealing with the encrypted partition of the drive using FileVault.

While playing with FileVault a discovered two things.  The first is that diskutil reports FileVault volume sizes incorrectly.  I spent a couple hours very confused on why my homedir was 200Gigs larger than the physical disk.  The second is a bit concerning, when I connected the old Mac hard drive and mounted the FileVault volume, it was able to decrypt this with the new Mac’s sudo password.  I’m not sure yet how that works, but I’d assume that the password is stored somewhere that’s root-accessible in a reversible (or decrypted?) format.  Somewhat concerning for a tool that you expect to protect your privacy.

Ultimately,  the transfer took so long I ended up convincing Apple to simply take the trade in with the promise of giving them the old drive.  I’m sure someday I’ll get a call about that…

My other Mac Book Pro has suffered significantly less, with the only real problem being somewhat dodgy internal fans.  I’ve had both fail to date.  After the headache of getting the first fan replaced, when the second fan bailed, I decided to skip the hassle and simply pull it out and run the machine without.  That’s worked “fine” for about a year, minus the box getting a little warm.  As it turns out, the fan is important (but apparently not important enough to use a quality part) and months of Texas heat and no internal fan have caused the display to fail to work.

Luckily for me, the video output from the laptop continues to work.  So I’ve simply hooked it up to my KVM and now have a shiny new ‘desktop.’  The only problem I’ve run into using this setup, is that the MBP doesn’t seem to have an option to run with the lid closed.  The only work around I’ve found is to power the machine on and, nearly instantly, close the lid.  This seems to work, tho as I switch between ports on my KVM the box occasionally loses track of the keyboard.

To work around this, I wanted my prompt to hilight the root of the current repository and also tell me what type of repo it is.

vcs_info does this, but I find the configuration quite inflexible, and some of the tests are quite expensive so I decided to quickly hack something together.

I arrived at

#!/usr/bin/env zsh
function __richo_pwd()
{
    local current=$PWD
    richo_prompt=no
    if [ -e ".svn" ]; then
        export richo_prompt="⚡"
    fi
    while [ "$current" != '/' -a $richo_prompt = "no" ]; do
    # for n in n; do
        if [ -e "$current/.git" ]; then
            export richo_prompt="±"
            break
        fi
        if [ -e "$current/.hg" ]; then
            export richo_prompt="☿"
            break
        fi
        if [ -e "$current/.bzr" ]; then
            export richo_prompt="⤴"
            break
        fi
        current=$current:h
    done
    if [ $richo_prompt != "no" ]; then
        if [ "$current" = "$HOME" ]; then
            repo="~"
            suff=${PWD##$current}
            export richo_pwd="$PR_BRIGHT_WHITE${repo}$PR_BRIGHT_BLUE$suff"
        else
            pref=$current:h
            suff=${PWD##$current}
            repo=$current:t
            richo_pwd="$pref/$PR_DULL_WHITE${repo}$PR_BRIGHT_BLUE$suff"
            export richo_pwd=${richo_pwd/$HOME/\~}
        fi
    else
        export richo_prompt='%#'
        export richo_pwd="${PWD/$HOME/~}"
    fi
}
__richo_pwd
add-zsh-hook chpwd __richo_pwd
PS1="${SHELL_COLOR}%(?.%m.\$(__richo_host) $PR_BRIGHT_RED%?)%b $PR_BRIGHT_BLUE\$richo_prompt $PR_RESET"
RPS1="$PR_BRIGHT_BLUE\$richo_pwd "

Which recurses back from the current directory, looks for the metadata for the 4 VCS systems that I use, and exports a character for my prompt and for the colored PWD.

Then I only run this on directory changes to keep things quick (Which does mean that `git init .` won’t update the prompt until you shuffle about a bit.

The net result is this

For some time now I’ve used openbox as my WM of choice (I worked it out the other day, it’s about a year since I migrated) and apart from needing to add one feature, it meets my needs pretty perfectly.

Divvy

One thing I did learn during the epic OSX wager though, was that divvy is a cool idea. Having the idea to quickly snap windows to segmented regions of your display can be a boon for people sitting between the floating and tiling models. I did feel that the Divvy implementation was a bit clumsy though, which meant I should…..

Them codes

<keybind key="W-Escape">
  <keybind key="q">
    <action name="Close"/>
  </keybind>
  <!-- Keybindings for resizing, ala divvy -->
  <!-- 30% -->
    <keybind key="C-h">
      <action name="MoveResizeTo">
        <x>0</x>
        <height>98%</height>
        <width>34%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="C-j">
      <action name="MoveResizeTo">
        <y>-0</y>
        <height>34%</height>
        <width>100%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="C-k">
      <action name="MoveResizeTo">
        <y>0</y>
        <height>34%</height>
        <width>100%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="C-l">
      <action name="MoveResizeTo">
        <x>-0</x>
        <height>98%</height>
        <width>34%</width>
      </action>
      <action name="Warp"/>
    </keybind>
  <!-- 50% -->
    <keybind key="h">
      <action name="MoveResizeTo">
        <x>0</x>
        <height>98%</height>
        <width>50%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="j">
      <action name="MoveResizeTo">
        <y>-0</y>
        <height>50%</height>
        <width>100%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="k">
      <action name="MoveResizeTo">
        <y>0</y>
        <height>50%</height>
        <width>100%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="l">
      <action name="MoveResizeTo">
        <x>-0</x>
        <height>98%</height>
        <width>50%</width>
      </action>
      <action name="Warp"/>
    </keybind>
  <!-- 66% -->
    <keybind key="S-h">
      <action name="MoveResizeTo">
        <x>0</x>
        <height>98%</height>
        <width>66%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="S-j">
      <action name="MoveResizeTo">
        <y>-0</y>
        <height>66%</height>
        <width>100%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="S-k">
      <action name="MoveResizeTo">
        <y>0</y>
        <height>66%</height>
        <width>100%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="S-l">
      <action name="MoveResizeTo">
        <x>-0</x>
        <height>98%</height>
        <width>66%</width>
      </action>
      <action name="Warp"/>
    </keybind>

    <!-- Corners -->
    <keybind key="b">
      <action name="MoveResizeTo">
        <x>0</x>
        <y>-0</y>
        <height>50%</height>
        <width>50%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="n">
      <action name="MoveResizeTo">
        <x>-0</x>
        <y>-0</y>
        <height>50%</height>
        <width>50%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="y">
      <action name="MoveResizeTo">
        <x>0</x>
        <y>0</y>
        <height>50%</height>
        <width>50%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="u">
      <action name="MoveResizeTo">
        <x>-0</x>
        <y>0</y>
        <height>50%</height>
        <width>50%</width>
      </action>
      <action name="Warp"/>
    </keybind>

    <!-- TinyCorners -->
    <keybind key="C-b">
      <action name="MoveResizeTo">
        <x>0</x>
        <y>-0</y>
        <height>34%</height>
        <width>34%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="C-n">
      <action name="MoveResizeTo">
        <x>-0</x>
        <y>-0</y>
        <height>34%</height>
        <width>34%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="C-y">
      <action name="MoveResizeTo">
        <x>0</x>
        <y>0</y>
        <height>34%</height>
        <width>34%</width>
      </action>
      <action name="Warp"/>
    </keybind>
    <keybind key="C-u">
      <action name="MoveResizeTo">
        <x>-0</x>
        <y>0</y>
        <height>34%</height>
        <width>34%</width>
      </action>
      <action name="Warp"/>
    </keybind>

  <keybind key="f">
    <action name="ToggleMaximizeFull"/>
  </keybind>
  <keybind key="S-f">
    <action name="ToggleFullscreen"/>
  </keybind>
</keybind>

This creates a set of bindings rooted off a modifier key (I used Windows+Escape because it’s a natural shape for my hands but far away from something I can hit by accident) and then used the nethack vi bindings because they’re drilled deep into my brain.

You’ll also see the `Warp` action attached to all of them.. if you’re not running my fork (which is still unmerged upstream, my fault) you’ll want to remove them unless you want to hear openbox be /very/ noisy about it.

From this you can do `W-Esc l` to place the current window on the right 50% of your screeen, `W-Esc y` for the top left, etc.

I think implemented modifiers, Shift for 66% and Ctrl for 34% for balanced splits. Tiling window managers (and even tmux, via the `next-layout` and `previous-layout` commands) support these, but I still need floating window support for the most part.

I’ll keep the speil to a minimum, but a $35 ARM SoC with ethernet, USB and enough hardware onboard to decode 1080p video on 1 watt.. you can see why I’m pretty stoked.

Recently, there was a call for mirrors and psych0tik raised our hands, we’re mirroring any and all content (presently, debian 6 iso’s) needed to get your pi up and running, though unfortunately only for those of you with ipv6 access at this stage.

Point your (ip6 capable) browser at alura.psych0tik.net/rpi to get the images!

EDIT: For anyone having issues with their system giving preference to A records, I have removed the A record from alura.psych0.tk

Generally, stashing occurs when I’m working on something that’s not ready for production or even feature complete enough to warrant publishing, and I need to rebase or start on something else. Nearly always I stash it and forget about it (even though my prompt yells at me when I have stashes)

The alternative is to check it into a wip/ or trash/ branch (depending on how confident I feel about the change in question being a Good Idea). This is useful for a stack of reasons:

1. It preserves some history about the idea (what else I was doing at the same time)
2. It makes tracking what you’re doing a lot simpler (because the stash stack is a pain at the best of times)
3. Most importantly, you can keep branching

The last one is the most relevant, a stash isn’t rooted to any particular point on the tree which means if you make an invasive change you’re going to struggle (which is a pain when the patch in question alters some core behaviour and was only barely working to start with)

If I know it’s going to be a problem that I take a lot of stabs at I’ll generally make it a branch like wip/ideas/short_description_of_approach for simplicity to begin with; and this will only get better in git 1.7.9 which adds a description attribute for branches.

Stashes are awesome for getting a clean tree so you can rebase or do some non-trivial merging, but for keeping ideas straight it’s a pain; to the point where I’m considering a hook to delete my stashes after a week so that I can just be rid of them.

Not wanting to go back to OSX after finally getting my encryption key back and being back in linux, I set about converting it to RGB values that urxvt can understand.

I realised two things while doing this-

1. plists are flaming piles of horror. Someone at Apple took bad acid.
2. Ruby is cool for bashing up quick scripts.

The results are up on github as itermcolors2xdefaults and it seems to work reasonably well.

The scheme in question was very feint so I added an option to multiply all the colors, but by and large it does what it says on the tin.

This gets worse if you already have config you like and goes totally sideways if you actually depend upon some of it to get a clean checkout.

The solutions isn’t complex- but isn’t obvious either. Most solutions I’ve seen involved invoking svn, then trying to throw it in the background after it creates metadata but BEFORE it begins creating files, and then nuke the files. Kludgy at best- I much prefer this approach.

#!/bin/sh
cd ~
mv .subversion _subversion
svn --config-dir _subversion up
echo "You must now merge _subversion into .subversion"