I wrote a few months ago about envbox, and I can say that it has proved useful to me many times over. One thing that felt unfinished was the way that envbox stores the key that it uses to encrypt all of the environment variables. It did move the problem from the shell/history to one of system security, which was acceptable. But there are better ways of storing credentials on most systems.
When I’m in front of a computer, I spend much of my time at the command line, logged into various systems, running commands. Now, there are two basic categories of commands: Commands that change - install a package, add a firewall rule, restart a service Commands that report - list installed packages, list firewall rules, list running services This post is about making the second category of commands more useful.
In my day to day work and evening and weekend side work, I do most almost all of my development working on remote systems. This has a number of advantages that are for another post, but this post is about one of the limitations. Most developers have a tool belt that they’re continually improving, and as I work on mine I come across commands - like hub that require1 putting a secret value into an environment variable, usually for authentication.
A few people have asked about my note-taking workflow and it’s been quite useful to me, so I thought I would describe what works for me. I’ve tried several of the popular note-taking tools out there and found them overbearing or over-engineered. I just wanted something simple, without lock-in or a crazy data format. So my notes are just a tree of files. Yup, just directories and files. It isn’t novel or revolutionary.
When I originally set up Octopress, I set it up on my Mac laptop using rvm, as recommended at the time. It worked very well for me until just a few minutes after my last post, when I decided to sync with the upstream changes. After merging in the changes, I tried to generate my blog again, just to make sure everything worked. Well, it didn’t, and things went downhill from there.
Last time I posted about git-annex, I introduced it and described the basics of my set up. Over the past year, I’ve added quite a bit of data to my main git-annex. It manages just over 100G of data for me across 9 repositories. Here’s a few bits of information that may be useful to others considering git-annex (or who are already knee deep in). Archive, not backup The website for git-annex explicitly states that it is not a backup system.
My Situation I have backups. Many backups. Too many backups. I use time machine to back up my macs, but that only covers the systems that I currently run. I have archives of older systems, some for nostalgic reasons, some for reference. I also have a decent set of digital artifacts (pictures, videos and documents) that I’d rather not lose. So I keep backups. Unfortunately, I’m not very organized. When I encounter data that I want to keep, I usually rsync it onto one or another external drive or server.
Last year, when I made my list of pros and cons comparing git subtrees with submodules, one of the downsides listed for subtrees was that it’s hard to figure out where the code came from originally. Well, it seems that the internet hasn’t been sitting on its hands. While the main repository remained stable, a couple forks took it upon themselves to teach git-subtree to keep a record of what it merges in a .
After a few months of managing my dotfiles with git, I felt the need to organize my vim plugins a little better. I chose to use pathogen (created by Tim Pope), which allows me to keep each plugin in its own subdirectory. It fits well with using git to manage dotfiles because git has two ways of tracking content from other repositories. The first is submodules, which keep a remote URL and commit SHA1 so that the other content can be pulled in after cloning.
I have quite a few dotfiles. I have so many that keeping them in sync is impossible with conventional methods. So, I turned to my old friend: version control. For a while, I kept them in subversion at work. This worked well as that was where I spent most of my time. Recently, however, I’ve wanted those same dotfiles to be available at home and other non-work areas. So, I investigated moving them over to a git repository.