Writings

We're now about 2 weeks into the Brood 2 Cicada hatch, which has been covering the Hudson Valley. It's spottier than I imagined it would be, but our neighborhood is clearly good ground for Brood 2, as the Cicada chorus is now loud enough to be heard inside with the windows closed during the day now, though I've only seen a few of the beasts in the yard. I've gotten a little used to that other worldly sound, and will have to say I'll miss it a little when this is over.

Radio Lab had great episode recently on the Cicada emergence, including a nice dissection of the sounds in the swarm. It turns out the chorus is really made of 3 different species with 3 different stages in their song. As this sun goes down this evening, and the cicadas start to quiet up, I can start to hear those pieces individually coming out. Like the tuning up phase in the orchestra, except in reverse.

And lastly, I learned today that modern noise cancelling in cell phones makes it basically impossible to record these sounds with a smart phone. Which is a shame. Otherwise I'd have uploaded our chorus to sound cloud.

Julien Danjou, the project technical lead for the OpenStack Ceilometer project, had some choice words to say about github pull requests, which resonates very strongly with me:

The pull-request system looks like an incredible easy way to contribute to any project hosted on Github. You're a click away to send your contribution to any software. But the problem is that any worthy contribution isn't an effort of a single click. Doing any proper and useful contribution to a software is never done right the first time. There's a dance you will have to play. A slowly rhythmed back and forth between you and the software maintainer or team. You'll have to dance it until your contribution is correct and can be merged. But as a software maintainer, not everybody is going to follow you on this choregraphy, and you'll end up with pull-request you'll never get finished unless you wrap things up yourself. So the gain in pull-requests here, isn't really bigger than a good bug report in most cases. This is where the social argument of Github isn't anymore. As soon as you're talking about projects bigger than a color theme for your favorite text editor, this feature is overrated.

After working on OpenStack for the last year, I'm completely spoiled by our workflow and how it enables developer productivity. Recently I went back to just using git without gerrit to try to work on a 4 person side project, and it literally felt like developing in a thick sea of tar.

A system like Gerrit, and pre-merge interactive reviews, lets you build project culture quickly (it's possible to do it other ways, but I've seen gerrit really facilitate it). The onus is on the contributors to get it right before it's merged, and they get the feedback to get a patch done the right way. Coherent project culture is one of the biggest factors in attaining project velocity, as then everyone is working towards the same goals, with the same standards.

My talk from the OpenStack summit is now up on youtube, where I walked people through the process of getting your idea into OpenStack. A big part of the explanation is what's going on behind the scenes with code reviews and our continuous integration system.

I'm hoping it pulls away some of the mystery of the process, and provides a more gentle on ramp to everything for new contributors. I'll probably be giving some version of this again at future events, so feedback (here or on youtube) is appreciated.

Saturday was a rainy day, so I decided to deal with switching out the root disk on my home server with an SSD that I purchased a couple weeks ago. It's part of my quest to get all the root disks of my machines off spinning media. My home server was a build from parts machine, that's long enough in the tooth that it won't boot from USB. So I found a stack of CDRs upstairs, of equally dubious age, burned an Ubuntu 12.10 server iso, and started the install.

Things were chugging along quite well until the installer was supposed to install additional packages. Then it bombed out (I blame the ancient CDRs). I was able to get it to at least install grub, and get the thing to boot back onto the network.

What I found myself with was a super minimal install. It didn't yet have a normal sources.list, it didn't have openssh-server, it didn't have ssh client even, it didn't have any of the normal even minimal server install tools. I had about 30 minutes of manual to typing to get the base apt repo in, and get me so I could ssh in from upstairs to drive the rest of the process. Boostrapping a Puppet Master This is the machine that's my puppet master. I had a copy of the oldroot over in one of my software raid arrays, so the moment I got that mounted, I dumped over the /etc/puppet this machine should have, and tried to just puppet my way up the rest of the way. I'd been on a month long kick to puppetize my home infrastructure, so this was a promising direction.

It turns out puppet up from nothing is a little harder when you are the puppetmaster, and dnsserver for the network as well. :) So it was about another 30 minutes of manually installing what was needed to get my puppetmaster started. Once that was up, I managed to get the first puppet agent run in, and it was epic. 45 minutes chugging away pulling down all the policies I needed, applying packages and configs, all the kind of magic that prevented me from spending my whole day trying to figure out how I had this server setup before.

It also showed me where my policy had holes. I've got xfs filesystems now, so xfsprogs need to be in the base case. My libvirt setup didn't actually install kvm, but in the super minimal install, that wasn't there. I hadn't gotten around to managing my openvpn server yet, that's in there now. If I was to do it again... One thing I really need is both a puppet and puppetmaster bootstrapping script. Using puppet to manage your puppetmaster is cool and all, but there is a bit of snake eating it's own tail to get you started that required a little more manual command slinging than I liked.

But, had I not had so much of my server policy encoded in puppet, I'd still be typing commands now to get that box up and running. So I'm sold on the whole process, even for a smallish IT environment, like a few home servers and remote guests.

STAR TREK: THE VIDEO GAME -- Shatner vs. Gorn Trailer - YouTube.

... love it.

Modafinil, which is marketed as Provigil in the United States, was first approved by the FDA in 1998 for the treatment of narcolepsy, but since then it’s become better known as a nootropic, a “smart drug,” especially among entrepreneurs. More recently, it has attracted traders like Borden who don’t just need a pick-me-up to get through a deadline; they need to be on, without a break, for months, even years at a time. via Modafinil Is Wall Street’s New Drug of Choice -- New York Magazine.

It reminds me a lot of A Deepness in the Sky, minus the giant spider aliens.

There are a couple of reasons why the bubble is sure to burst. The first is just that it’s a bubble, and any chart which looks like the one at the top of this post is bound to end in tears at some point. But there’s a deeper reason, too — which is that bitcoins are an uncomfortable combination of commodity and currency. The commodity value of bitcoins is rooted in their currency value, but the more of a commodity they become, the less useful they are as a currency. via The Bitcoin Bubble and the Future of Currency — Money & Banking — Medium.

Definitely one of the best articles I've read on Bitcoin. I think the idea of bitcoin as commodity actually makes a lot more sense, given that it's an artificially constrained resource that's "mined".

We lost a few features moving mhvlug.org from Drupal 6 to Drupal 7, as modules just didn't exist. One of the ones I missed the most was the Planet function provided by UD Planet. This was an extremely simple to use module that let you have an attractive Planet (a collection of user blogs) on your Drupal site. The original authors of the module have long since gone inactive. So this past weekend I decided to just port it to D7 and be done with it. It took about 8 hours, and now we have Easy Planet!

Easy Planet 1.1 is now out. This is a straight port of UD Planet to D7. The only functionality which isn't there is the disabling of aggregator menu items, which I'm not convinced was a good idea in the first place. It's live on http://mhvlug.org/planet, for anyone that wants to see what it looks like.

One of the most important things to me was smooth transition from UD Planet installation. Because mhvlug.org was a D6 -> D7 migration, I still had udplanet tables and settings in my database. I wanted the experience of easyplanet to be: turn it on, all your stuff is back. I managed to get it there last night, so I'd be extremely interested in others that are moving from UD Planet -> Easy Planet to make sure it's as seamless for them.

For more info, and to download the code, check out the project site.

Last week I bought myself one of the Samsung Arm Chromebooks. My theory is that when at conferences this is a nice form factor, light, with a good keyboard for taking notes (interactive etherpad is a key piece of OpenStack design summits), that's going to last a conference day. It's also super cheap, so if anything happens to it, I don't care.

Unlike a phone/tablet, this still means I have sane ssh access, and possibly able to still do code through an ssh connection to a server somewhere. We'll see how the experiment holds up over the next month or so.

Honestly, the thing that's going to give me the biggest headache is the touchpad, which is actually pretty good. But I'm someone that has 10+ years of muscle memory on the Thinkpad track point, and I don't think I'll ever get more than tolerant of touchpads.

10 years ago today I was on a plane, back from Portland, Oregon, to experiment on something new. For the previous 3 months I'd been working towards a kickoff for a local Linux Users Group.

We had a venue: the Mid Hudson Library System Auditorium. We had a date and time:  Wed the 5th of March, 6pm. We had a speaker: Michael Kaegler talking on Linux Firewalling. We had a mailing list and a website, and could clearly see there was interest in the group. But we'd never had a meeting, so this was the moment of truth.

But I was on a plane, racing to get back for the meeting. A month prior my job had changed, I'd started working on OpenHPI, and I'd picked up some standards work, and that meant a trip out of Portland for a 2 day standards meeting with a lot of Intel folks. I managed to get a flight which "should" get me back in time, but I had a plan B to have a Mike Salerno kick off the meeting in my absence. I landed at 5:15, was in my car by 5:30. The meeting was at least 35 minutes away, and there was traffic. Plan B was going to have to be good enough.

When I walked in the door I was blown away. The room was packed! There were at least 35 folks when I arrived, and over the course of the meeting it grew to 50. Wow. I was hoping that it would be more than just me and a few coworkers, but never had I imagined this. I wondered how long this experiment would run, fully imagining that after two years we'd run out of steam and interest and move on.

It's been 10 years, and MHVLUG is still running strong, better than ever.

For everyone that was part of our first decade, making MHVLUG successful: Thank You. This is a community first, and it's the people that make this awesome.

For everyone that hasn't checked us out yet, our 10th Anniversary meeting is tomorrow. We're going to be talking about: Linux where you least expect it. There will be cake, coffee, and conversation. There will be time for socializing and mixing, to become part of this dynamic community. Join us as we start decade number two.