Sharing a 2560×1600 monitor between 2 MacBooks using a displayport KVM

I have two MacBook Pros (one for work and one personal) that I want to connect to a 2560×1600 resolution Dell monitor I recently purchased. It seems like a straightforward task, just buy a KVM with displayport in/outs and hook everything up. However there’s one small glitch and it’s in the way KVMs operate.

When you switch from computer 1 to computer 2 on most KVMs, the display for computer 1 is simply turned off and the display for computer 2 is turned on. This simple act will cause all your windows on computer 1 to be resized and repositioned.

Some KVMs will emulate the monitor for non-active displays, in this case tricking Computer 1 into believing the display is still connected. This feature is available in some higher-end KVMs.

So it should be simple right? Just fork out a bit more cash and get a KVM that supports this feature. Unfortunately after hours of searching I could not find a single displayport KVM that does this. And there are more than a few discussions online pointing to the dreary possibility that none exist.

There is an option to downgrade to dual link DVI connectors and search yet again for a DVI KVM that supports this feature. However, the MacBooks have mini-displayports and would require an adaptor which unfortunately also takes up a usb slot (and is about $100).

Fortunately, this problem can be solved in software. A utility called Stay can save window configurations and you can either restore them manually or have them automatically restored when a monitor is connected/disconnected.

Stay, in combination with a cheap displayport KVM, should solve your problem of sharing a 2560×1600 monitor between 2 MacBooks.

If you also need to share bluetooth devices, you will want to check out Teleport, which works pretty well for keyboard/mouse/trackpad sharing.

Issue tracking and wikis

Recently I made a stupid, sleep-deprived error. I won’t go into too much detail, as it’s unimportant, however I made some sweeping changes to a number of of my git repositories. Rather than properly merging the changes into my project’s respective Github repositories I decided to simply delete the Github repos, create new ones and upload the changes from my local repo.

Had I been more careful, or paid more attention to the numerous warnings during this process, I would have made backups of my wiki and issue tracker data. Unfortunately I did not and the next day when I went to make some updates to the wiki of one of my projects I was hit with the realization that the data was lost forever.

Issues and documentation are part of your project

The overall insight this experience has given me is that issues and documentation are part of your project. Every file in your project is stored in the same repository, why isn’t the issue tracker and wiki data stored in that same repo?

Granted my mistake was a stupid one, stemming from carelessly performing operations which cannot be undone. However consider the case of moving your central repository from Github to another service or private host. The move isn’t as simple as changing the origin and pushing to the new repo, instead you have to backup the issues/wiki and transfer that in a second step. Sometimes transferring that data is difficult, especially if the tools provided by the new host are radically different.

Having all your issue/wiki data stored in the same repo as your source code means that there are (likely) multiple copies of that data on many different machines. Changing hosts for the central repository is a simple matter of pushing to a new origin. Developers can use their preferred tools to work with issues and documentation.

I’ve done a cursory search for issue trackers/wikis which are designed to be included in the main git repository and have found ticgit which takes care of issue tracking. I haven’t had a chance yet to evaluate it, but plan on doing so in the near future. I haven’t yet found a solution for a wiki.

Ideally I would like both an issue tracker and wiki with a similar interface (as much as that is possible). If I’m unable to find a suitable solution I will likely take this up as my next project. Here are some of the features that I’m looking for:

Version Control
Changes to issues or wiki should be tracked by version control.
New issues or changes should be associated with a user (git name + email + key).
Editing should be allowed through a number of tools (web, command line, text editor/IDE) and should support markdown format.
A program can monitor the repo for changes and alert users via email when changes occur.