Rather than authenticate to a SMTP server to send email, which is fraught with potential security issues and hassles, I use a SSH tunnel to the machine running my mail server. This is automatic, easy to configure both for the mail server and mail client, and incredibly secure. It’s good stuff.

The downside, if there is one, is that the tunnel has to be active to be able to send email messages, and SSH tunnels sometimes disconnect a bit too silently particularly on unstable (wireless) connections. I (and others, I suspect) have had some success with integrating the tunnel connection with pre- and post- connection hooks, so that the network manager automatically creates a tunnel after connecting to the network. but this is a flawed solution that produces uneven results.

Recently I’ve discovered this program called “AutoSSH,” which creates an SSH tunnel and tests it regularly to ensure that the tunnel is functional. If it isn’t, AutoSSH recreates the tunnel. Great!

First start off by getting a copy of the program. It’s not part of the OpenSSh package, so you’ll need to download it separately. It’s in every pacakge management repository that I’ve tried to get it from. So installation, will probably involve one of the following commands at your system’s command line:

apt-get install autossh
pacman -S autossh
yum install autossh
port install autossh

When that’s done, you’ll issue a command that resembles the following

autossh -M 25 -f tychoish@foucault.cyborginstitute.net -L 25:127.0.0.1:25

Really, the important part here is the “autossh -M 25” part of the command. This tells autossh to watch (“monitor”) port number 25 on the local system for a tunnel. The rest of the command (e.g. “-f -L 127.0.0.1:25:127.0.0.1:25 mailserver@tychoish.com -N") is just a typical call to the ssh program.

Things to remember:

• If you need to create a tunnel on a local port with numbered lower than 1000, you’ll need to run the autossh command as root.
• SSH port forwarding only forwards traffic from a local port to a remote port, through an SSH connection. All traffic is transmitted over the wire on port 22. Unless you establish multiple tunnels, only traffic sent to the specific local port will be forwarded.
• Perhaps it’s obvious, but there has to be some service listening on the specified remote end of the tunnel, or else the tunnel won’t do anything.
• In a lot of ways, depending on your use case autossh, can obviate the need for much more complex VPN setups for a lot of deployments. Put an autossh command in an @reboot cronjob, with an account that has ssh keys generated, and just forget about it for encrypting things like database traffic and the like.

Onward and Upward!

I don’t read romance literature.

It’s not my thing, which isn’t saying much: there’s a lot of literature that I don’t tend to consider “my thing,” for one reason or another. I don’t really read fantasy, or horror, and I’m even picky within science fiction. There are enough books out there and there is only so much time. At least that’s what I tell myself.

Nevertheless, Susan Groppi wrote a great post about coming out as a reader of romance that I found useful. I’m also reminded of comments that N. K. Jemison made about the in progress merging of the fantasy and romance genres (sorry if I’ve miss-cited this), and I’ve been thinking about how I view Romance fiction, and perhaps a bit more generally about genre fiction ghettos.

In general, I think Romance has merit, both because it’s entrancing and I think fiction which captures people’s imaginations and interest I worthwhile and important to not dismiss because it’s commercial, or the readership/writers are largely women. There are potential problems with romance, at least insofar as we typically envision it: with strong hetero tendencies, an idealization of monogamy as a social practice and marriage as an institution, and the potential to accept a very conventional conceptualization of gender. I’m sure some romance literature has been able to engage and trouble these troupes productively, but I think it’s a potential concern.

Having said that, I’m not sure that Romance has a lot of future as a genre. This is to say that I think many of the elements of romance--female characters, and an engagement with sexuality and relationships--will increasingly merge into other genres. Romance as an independent genre will linger on, but I think the “cool stuff happening in the Romance field,” will probably eventually move out into corners of other genres: thriller, fantasy, maybe science fiction.

Actually, as I think about this, it’s probably backwards. I think it’s less that Romance doesn’t have a future, as it is that the future of most popular literature lies in engaging with romance-elements and other aspects of romance stories the context of non-romance specific styles. This kind of thing is happening, and I think it’ll probably continue to happen.

I wish I could speak with greater certainty about the reasons why romance literature enjoy higher readership, or what elements of romance stories can be transplanted to other genres, but I think these are probably questions which are beyond the scope of this post. Thanks for reading!

So I’ve started knitting again.

Shocking.

I’ve not been knitting very much in recent months, because I’ve had less time, because I’ve been focusing my energy on other projects: keeping my head above water, writing, dancing, singing, etc. It’s a shame too, because knitting is a great deal of fun, it’s pretty rewarding, and it’s something that I’m incredibly good at.

I suppose at one point there were a lot of knitters who read this blog, but I suspect many of them don’t so much any more. Anyway, I hope this post won’t alienate everyone who reads this.

First up, for some project review:

• I have a cabled sweater in progress that I’m working on the first sleeve at the moment. I’m afraid I’m going to run out of yarn (but I have a plan!) and frankly cables have never really been “my thing,” but this is the only thing that remains that I was working on when I left the Midwest, so there’s nostalgia and I do want to finish it. The biggest problem, I think, is that unless I move north a lot, I’m not going to live in a place where I can really wear something like this.
• I have a sweater in jumper-weight Shetland (i.e. fingering weight) wool that I’m knitting for a friend. I have the collar and the sleeves to do, but it’s very plain and a very straightforward knit. I just need to do it. This is probably the next thing on my list. It’s been on hiatus since May.
• I’m making socks. As I write this, I have just completed a pair of socks that I started in May. They’re simple, and plain (which is how my socks tend to be) using Dyebolical Yarn. I also got to use a set of Blackthron Needles that my mother got for my birthday. Both are quite wonderful. I think I’ve discovered how much knitting can be done on a commute, and I do expect to do a lot more commute knitting, but I need to find a way to balance knitting with writing and reading on the train. Perhaps some sort of morning/night split.

Aside from finishing the socks and immediately casting another pair, I’ve been doing a lot of “yarn stash” reorganization and trimming. This last week or so I’ve gotten inspired to reevaluate all of the stuff that I have to see what I really need in my life and what I’m just keeping because it’s there. I’ve been through my clothing, the book collection, and the yarn.

Although I’ve done “stash culls” before I felt like my collection of yarn had a lot of stuff in it that I got without any intention of a project, or for any reason other than “I might like to make something with it some day.” I’ve never really been a knitter when I’ve had a real budget for hobbies and entertainment, nor have I ever knitted at such a moderate pace. So I made the decision to not keep yarn around just for insulation, and just get the yarn that I really want to knit with rather than what I feel like I ought to knit with because it’s in the bin. It’s been quite liberating.

I’m also, as I sit knitting, thinking about the overlap between what I do professionally (documenting technical solutions and systems administration practices) and pattern writing for knitters.

There’s a lot of overlap in how I write and think about both, enough to inspire me to think about doing more knitting related writing. *As if I didn’t have enough projects already.

In any case, I don’t know that I’ll blog regularly about knitting as I continue to knit more, but it might come up from time to time. You have been warned.

Onward and Upward!

I mentioned in a recent update post, that I had recently gotten a new cell phone, which given who I am and how I interact with technology means that I’ve been thinking about things like the shifting role of cell phones in the world, the way we actually use mobile technology, the ways that the technology has failed to live up to our expectations, and of course some thoughts on the current state of the “smart-phone” market. Of course.

I think even two years ago quasi-general purpose mobile computers (e.g. smart phones) were not nearly as ubiquitous as they are today. The rising tide of the iPhone has, I think without a doubt, raised the boat of general smart phone adoption. Which is to say that the technology reached a point where these kinds of devices--computers--are of enough use to most people that widespread adoption makes sense. We’ve reached a tipping point, and the iPhone was there at the right moment and has become the primary exemplar of this moment.

That’s probably neither here nor there.

With more and more people connected in an independent and mobile way to cyberspace, via either simple phones, (which more clearly matches Gibson’s original intentions for the term,) or via smart phones I think we might begin to think about the cultural impact of having so many people so connected. Cellphone numbers become not just convenient, but in many ways complete markers of identity and person-hood. Texting in most situations overtakes phone calls as the may way people interact with each other in cyberspace, so even where phone calls may be irrelevant SMS has become the unified instant messaging platform.

As you start to add things like data to the equation, I think the potential impact is huge. I spent a couple weeks with my primary personal Internet connection active through my phone, and while it wasn’t ideal, the truth is that it didn’t fail too much. SSH on Blackberries isn’t ideal, particularly if you need a lot from your console sessions, but it’s passable. That jump from “I really can’t cut this on my phone,” to “almost passable” is probably the hugest jump of all. The series of successive jumps over the next few years will be easier.

Lest you think I’m all sunshine and optimism, I think there are some definite short comings with contemporary cell phone technology. In brief:

• There are things I’d like to be able to do with my phone that I really can’t do effectively, notably seamlessly sync files and notes between my phone and my desktop computer/server. There aren’t even really passable note taking applications.
• There are a class of really fundamental computer functionality that could theoretically work on the phone, but don’t because the software doesn’t exist or is of particularly poor quality. I’m thinking of SSH, of note taking, but also of things like non-Gmail Jabber/XMPP functionality.
• Some functionality which really ought to be more mature than it is (e.g. music playing) is still really awkward on phones, and better suited to dedicated devices (e.g. iPods) or to regular computers.

The central feature in all of these complaints is software related, and more an issue of software design, and an ability to really design for this kind of form factor. There are some limitations: undesirable input methods, small displays, limited bandwidth, unreliable connectivity, and so forth. And while some may improve (e.g. connectivity, display size) it is also true that we need to get better at designing applications and useful functionality in this context.

My answer to the problem of designing applications for the mobile context will seem familiar if you know me.

I’d argue that we need applications that are less dependent upon a connection and have a great ability to cache content locally. I think the Kindle is a great example of this kind of design. The Kindle is very much dependent upon having a data connection, but if the device falls offline for a few moments, in most cases no functionality is lost. Sure you can do really awesome things if you assume that everyone has a really fat pipe going to their phone, but that’s not realistic, and the less you depend on a connection the better the user experience is.

Secondly, give users as much control over the display, rendering and interaction model that their software/data uses. This, if implemented very consistently (difficult, admittedly,) means that users can have global control over their experience, and users won’t be confused by different interaction models between applications.

Although the future is already here, I think it’s also fair to say that it’ll be really quite interesting to see what happens next. I’d like a chance to think a bit about the place of open source on mobile devices and also the interaction between the kind of software that we see on mobile devices and what’s happening in the so-called “cloud computing” world. In the mean time…

Outward and Upward!

Surely I’m not the only person who’s wanted to run multiple distinct instances of the emacs daemon at once. Here’s the use case:

I use one laptop, but I work on a number of very distinct projects many of which involve having a number of different buffers open, most of which don’t overlap with each other at all. This wouldn’t be a huge problem except that I’ve easily gotten up to two hundred buffers open at once. It can get a bit confusing. Particularly since I never really need to touch my work related stuff when I’m writing blags, and my blogging and website design buffers never intersect with fiction writing.

If I weren’t using emacs in daemon mode (that is, invoked with the “emacs --daemon” command) I’d just open separate instances of emacs. The problem with that is, when X11 crashes (as it is so wont to do) the emacs instances crash too and that’s no good. Under normal conditions if you start emacs as a daemon, you can only run one at a time, because it grabs a socket and the emacsclient program isn’t smart enough to be able to decide which instance of emacs you want. So it’s a big ball of failure.

Except I figured out a way to make this work.

In your .emacs file, at the very beginning, put the following line:

(setq server-use-tcp t)

In the default configuration, the emacs daemon listens on a UNIX/system socket. However, in emacs can also, with the above option set, can also listen for connections over TCP. I’ve not yet figured out how to create the required SSH tunnel to make this particularly cool, but it makes this use case possible.

Now, when you start emacs, use commands in the following form:

emacs --daemon=tychoish
emacs --daemon=work

Each server process creates a state file in the “~/.emacs.d/server/” folder. If you are using version control on this file, you may want to consider explicitly ignoring this folder to avoid confusion.

To open an emacs client (i.e. an emacs frame attached to the emacs daemon,) use commands in the following form

emacsclient --server-file=tychoish -c -n
emacsclient --server-file=work -c -n

You may append a file name to open a specific client with one of these emacsclient invocations, or use any of the other emacsclient options. Although these commands are long, I have integrated them into my default zsh configuration as aliases, and as key shortcuts in my window manager. So opening a frame on a specific emacs instance isn’t particularly difficult.

And that’s it. It just works. I have the following two lines in my user’s crontab file:

@reboot    emacs --daemon=tychoish
@reboot    emacs --daemon=work

These lines ensure that the usual (and expected) named emacs daemons are started following reboot. More generally, the @reboot cronjob is great for making the “my computer just rebooted, and now I have to fuss over it for ten minutes before I can work” problem seem much less daunting.

In conclusion I’d like to present one piece of unsolicited advice, and ask a question the assembled.

• Advice: Even though it’s possible to create a large number of emacs instances, and on modern systems the required RAM is pretty low, avoid this temptation. The more emacs instances you have to juggle the greater the chance that you’ll forget what buffers are open in what instance. Undesirable.
• Question: Is there a way to get the value of server-name in into emacs lisp so that I can if things against it? Haven’t figured this one out yet, but it seems like it would be nice for conditionally loading buffers and things like org-mode agenda. Any ideas?

Onward and Upward!

I wrote a bit about sacred harp singing for a few months about a year ago, when I was really starting to get into it, and then I mostly stopped. I’ve had a few singing related experiences recently that I think are worth recounting, even if they’re a bit disjointed. So I’ll just hop in and hope that it adds up to something in the end. Also, if you’re not familiar with Sacred Harp Singing, I’m sorry if there isn’t a lot of sub tittling. Thanks for reading!

I was hanging out with R.F. and we were flipping through my copy of the sacred harp, and he was trying to get how the relative pitching thing works (having more formal experience singing with choirs and what not, and a sense of pitch that’s way more closely tied to a piano than mine.) and he said something like “so this one would start ‘here?'” I think it was 300, and I have no clue how “right,” I was or what inspired this, but his pitch was about a step and a half (I think,) high, and so I gave something that was more or less where I thought the song was supposed to sit. We sang through a little bit of it, and it seemed to work.

I’ve never really had a lot of interest in being able to offer pitches to a class of Sacred Harp singers, beyond the very selfish ability to lead signings without needing to make sure that someone who can offer keys in attendance.

I’m working on memorizing the book--strategically, of course-- as I can. This makes signings more fun because you can look at people, while singing rather than having your nose in a book the whole time. While there aren’t songs that I can safely leave the book closed for the shapes, I know the tunes (mostly bass parts) and words to most of the common ones (e.g. 178, 155, 89, 312b, 355, 300, 146, 148, 153, 112, 422, 209, 189, 186,) save a few middle verses that are sung rarely. I don’t think of my memory as being particularly good for this kind of information, but it’s nice to have reality prove you wrong.

One of the things that made Sacred Harp “click” for me when I really started to get into it was that I had the good sense to sing bass. My voice is pretty low, so this seems to fit, and I think staying in one section for a long time helped solidity my sense of the music.

Since March/April, or thereabouts, I’ve started singing tenor (the lead/melody) a bit. It’s a stretch for my voice, and I’m slightly more prone to loosing track of the key when singing higher notes (a not uncommon problem,) but it’s good for my brain, and I think it makes me a better singer and leader. I’ve mostly done this at local singings, and smaller signings when there are enough basses, or for a few songs at a bigger singing when the mood strikes.

I’m thinking of doing this more often, and at more singings, as part of an effort to become a better singer.

I think it’s easy (at least for me) particularly in accounts like this to focus on the singing, the technical aspects of the music, and the texts used. And all of these components contribute to what makes singing so great: its a gestalt experience, but I think its easy to gloss over the best part of being a singer. Which is, of course, all the other singers.

Being a “community guy,” I think it might be easy for me to wax poetic about how great sacred harp singings are--and they are--but I think there’s something deeper and specific about singing communities that make them more accepting, more engaged, more inclusive than other communities (dancing, writing, professional,) that I’ve been involved in

Maybe it’s that singing is a more transcendent experience that the focal points of other communities to begin with so people are willing to connect a bit more. Maybe the fact that singings are sometimes (often?) held in people’s homes is a factor. Maybe the extreme inclusiveness combined with the somewhat substantial learning curve creates the right environment to foster a strong and self selecting community. Perhaps all of the travel to all day singings and conventions, combined with the effort to arrange socials, unifies the community.

I’m not sure, but I’ve met a bunch of great people singing, and people with whom I share more than just sufficient common interest in a shared activity. I’m not sure every singing community is like this, but the conversations and connections I’ve had with other singers have been depthy, interesting, and have expanded beyond singing.

Git is a very… different kind of software. It’s explicitly designed against the paradigm for other programs like it (version control/source management) and to make maters worse most of it’s innovations and eccentricities are very difficult to create metaphors and analogies around. This is likely because it takes a non-proscriptive approach to workflow (you can work with your collaborators in any way that makes sense for you) and more importantly it lets people do away with linearity. Git makes it possible, and perhaps even encourages, creators to give up an idea of a singular or linear authorship process.

That sounds great (or is at least passable) in conversation but it is practically unclear. But even when you sit down and can interact with a “real” git repository, it can still be fairly difficult to “grok.” And to make matter worse, there are a number of very key concepts that regular users of git acclimate to but that are still difficult to grasp from the ousted. This post, then, attempts to illuminate a couple of these concepts more practically in hopes of making future interactions with git less painful. Consider the following:

The Staging Area

The state of every committed object (i.e. file) as of the last commit is the HEAD. Every commit has a unique identifying hash that you can see when you run git log.

The working tree, or checkout, is the files you interact with inside of the local repository. You can checkout different branches, so that you’re not working in the “master” (default or trunk) branch of the repository, which is mostly an issue when collaborating with other people.

If you want to commit something to the repository, it must first be “staged” or added with the git add command. Use git status to see what files are staged and what files are not staged. The output of git diff generates the difference between the HEAD plus all staged changes, and all unstaged changes. To see the difference between all staged changes and HEAD use the “git diff --cached”.

The staging area makes it possible to construct commits in very granular sorts of ways. The staging area makes it possible to use commits, less like “snapshots” of the entire tree of a repository, and rather as discrete objects with that contain a single atomic change set. This relationship to commits is enhanced by the ability to do “squash merges” and squash a series of commits in a rebase, but it starts with the staging area.

If you’ve staged files incorrectly you can use the git reset command to reset this process. Used alone, reset is a non destructive operation.

Branches

The ability to work effectively in branches is the fundamental function of git, and probably also the easiest to be confused by. A branch in git, fundamentally, is just a different HEAD in the same repository. Branches within a single repository allow you to work on specific sets of changes (e.g. “topics”) and track other people’s changes, without needing to make modifications to the “master” or default branch of the repository.

The major confusion of branches springs from git’s ability to treat every branch of every potentially related repository as a branch of each other. Therefore it’s possible to push to and pull from multiple remote branches from a single remote repository and to push to and pull from multiple repositories. Ignore this for a moment (or several) and remember:

A branch just means your local repository has more than one “HEAD” against which you can create commits and “diff” your working checkout. When something happens in one of these branches that’s worth saving or preserving or sharing, you can either publish this branch or merge it into the “master” branch, and publishes these changes.

The goal of git is to construct a sequence of commits that represent the progress of a project. Branches are a tool that allow you to isolate changes within tree’s until you’re ready to merge them together. When the differences between HEAD and your working copy becomes to difficult to manage using git add and git reset, create a branch and go from there.

Rebase

Rebasing git repositories is scary, because the operation forces you to rewrite the history of a repository to “cherry pick” and reorder commits in a way leads to a useful progression and collection of atomic moments in a project’s history. As opposed to the tools that git replaces, “the git way” suggests that one ought to “commit often” because all commits are local operations, and this makes it possible to use the commit history to facilitate experimentation and very small change sets that the author of a body of code (or text!) can revert or amend over time.

Rebasing, allows you to take the past history objects, presumably created frequently during the process of working (i.e. to save a current state) and compress this history into a set of changes (patches) that reflect a more usable history once the focus of work has moved on. I’ve read and heard objects to git on the basis that it allows developers to “rewrite history,” and individuals shouldn’t be able to perform destructive operations on the history of a repository. The answer to this is twofold:

• Git, and version control isn’t necessarily supposed to provide an consistently reliable history of a projects code. It’s supposed to manage the code, and provide useful tools to managing and using the history of a project. Because of the way the staging area works, sometimes commits are made out of order or a “logical history object” is split into two actual objects. Rebasing makes these non-issues.
• Features like rebasing are really intended to happen before commits are published, in most cases. Developers will make a series of commits and then, while still working locally, rebase the repository to build a useful history and then publish those changes to his collaborators. So it’s not so much that rebasing allows or encourages revisionist histories, but that it allows developers to control the state of their present or the relative near future.

Bonus: The git stash

The git stash isn’t so much a concept that’s difficult to grasp, but a tool for interacting with the features describe above that is pretty easy to get. Imagine one of the following cases:

You’re making changes to a repository, you’re not ready to commit, but someone writes you an email, and says that they need you to quickly change 10 or 12 strings in a couple of files (some of which you’re in the middle of editing,) and they need this change published very soon. You can’t commit what you’ve edited as that might break something you’re unwilling to risk breaking. How do you make the changes you need to make without committing your in-progress changes?

You’re working in a topic branch, you’ve changed a number of files, and suddenly realized that you need to be working in a different branch. You can’t commit your changes and merge them into the branch you need to be using that would disrupt the history of that branch. How do you save current changes and then import them to another branch without committing?

Basically invoke git stash which saves the difference between the index (e.g. HEAD) and the current state of the working directory. Then do whatever you need to do (change branches, pull new changes, do some other work,) and then invoke git stash pop and everything that was included in your stash will be applied to the new working copy. It’s sort of like a temporary commit. There’s a lot of additional functionality within git stash but, that’s an entirely distinct bag of worms.

Onward and Upward!

… when you’re a tycho.

I’ve not been blogging very much. There were even two weeks where I totally forgot to post anything to the blog. I’m not sure if there’s been a hiatus of that length at any other point in the last three years. Strange, but not bad. I’ve been writing--not as much as I’d like, but enough--but nothing has really managed to filter through to the blog. Seems, then, like a good time for a general “what the hell have you been up to and what are you working on post?”

I’ve been plugging away on the novel project for a while I’m in the home stretch: two and a half chapters to write. I know I can write a chapter in a couple of weeks if I put my mind to it, and have a good weekend day to do nothing other than sit around and write. I’ve discovered some things about the story that have made it much easier and clear for me to write. A character that I thought was the main is a horrible point-of-view character, I have a more clear idea of what I’ve been trying to get after the entire story, I’ve started to really like the project again. The problem now, is just finding time to finish it.

I moved nearly two months ago: it was a good thing indeed. I’m closer to friends and activities that I find fulfilling. Although I’m not in the heart of my city, I have a train pass and am a block away from a train station that will get me into the city pretty much whenever I want. Train passes are a fantastic innovation, and my only real complaint (on this note) is that for varied historical reasons Tran service in America is woefully pathetic. But it’s great to be in a place where public transit is a viable option for most commuting.

I’ve recently started dating someone, which is a terribly atypical experience for me given how independent and quirky I am in “default mode.” Nifty though, and utterly unintended: but there’s something delightful about the whole deal. Who am I to argue?

And by “recently started” I mean almost three months ago. Right.

I got a new phone. After a long time with a Blackberry Bold, I took an upgrade and got the new Blackberry Torch. I had been strongly pondering an Android phone, but the one I wanted most (HTC EVO) is on a network that I’d like to avoid, and the other offerings seem lackluster. Blackberries have never (rarely?) been exciting, but they have worked, and there are some features that make sense to me (massively configurable ring/tone behavior, central messages feed that all applications can create entries in.) Having said that, I’m not wild about being on a closed platform, though I think we shouldn’t delude ourselves into thinking that from the user’s perspective that Android is an open platform.

With a web browser that is basically mobile Safari, and applications to do the major things I need to do (IM, email, calendar, GPS, web browsing, address book, twitter, alarm clock, ebook reading, emergency ssh,) and a device that is build wonderfully, I couldn’t be happier. I wish there was a better solution for writing/note taking/outlining for the Blackberry, but these things happen.

It’s probably a symptom of the commute as much as anything but I’ve had a hard time figuring out how to write on the train. I did ok for a while, and then I’ve had a horrible time with it for the past few weeks. The new plan is to do a little reboot of my organizational system and to switch back to using the laptop as my only computer.

The first part, the organizational reboot, is important because I’m not used to thinking about my available time as existing in the “shape” that it currently exists. If I’ve learned one thin in the past couple of years, its that staying organized and on top of ones personal project is almost entirely dependent upon being able to successfully break apart big projects into “doable” pieces that you can tackle in the time you have. That sounds easy, but it’s pretty hard to know what your project will require and what your near-future is going to hold enough to be able to get everything to line up. Sometimes it requires little reboots.

The second, much more technological remedy, is mostly that while the separation between my work system (and tasks) and my personal system (and tasks) has been nice, in practice it doesn’t work that well. The context switch between the train and the office is too hard, and not being able to just unplug and shut down, means that the start up/shut down costs for the context switches are simply too high and I’m the one who feels the impact. So re-merging my systems seems to be the way to win this game, at least for the moment.

I think I’m going to ultimately invest in a hot spare laptop that’s mostly identical to my current laptop to reduce some of the anxiety regarding the “what happens if my machine croaks,” worry. Which is always a fear.