I've been using Google Reader daily since December, 2006. I use it to read web sites that interest me. Although some people have complained that it hasn't been updated in a long time, or that it lacks meaningful social aspects, I've been perfectly happy with it.

I don't generally read the news on my mobile device. Any sharing of news I might do would likely occur manually through email or Twitter, rather than some button on the Google Reader site. The lack of new features is actually something I like: it's a product that works well, and has continued to satisfy my very modest needs.

But like all good things, Google Reader is coming to an end. There's a general scrambling amongst Reader users who are looking for alternatives, and there are a number of solid contenders out there. Most of the current crop are offering features that Google lacked, which means they're not features in which I have a strong interest. I expect I'll wait a little longer to see what options mature in the time before Reader officially shuts down.

I think my preferred solution will be to run my own RSS aggregator again. Although the format hasn't advanced substantially in the half-decade that I've been using it, I think the tools available to produce and consume RSS have matured quite a bit.

Just a year after adopting Google Reader, I went all-in with Google for Domains. I updated my DNS MX records, and handed control of all of my email to Google. I eventually switched from using a desktop email client to using Google's web interface exclusively. On the whole, since November 2007, I've been pretty happy. The Google experience is perfectly acceptable.

But the shuttering of Google Reader has me asking: "What else?" It's extremely unlikely that Google would retire their mail service, but what if? Since I'm expecting to run my own RSS aggregator in the near future, does it make any sense to reclaim any other services back from Google?

Way back when, the big draw to Google Mail -- for many, including me -- was the superb web-based experience. From any computer with a web browser, I could access my email. Self-hosted web-mail solutions like SquirrelMail, Roundcube, and Citadel all valiantly tried to compete, and I'm sure they each have a healthy following; but they didn't do it for me.

In today's world, with the proliferation of smartphones, I have convenient access to any email solution, whether mine or someone else's. Web mail is no longer a strong distinguishing factor for a self-hosted email solution. I suspect I could get by without web mail at all by using my phone. If I'm not using web mail for on-the-go access, it makes little sense to use web mail for desktop access. It's been a long time since I've used Thunderbird -- or any other desktop email client -- but I suspect the learning curve would be mild.

Over time, Google's integration of their calendar function and their chat functions made the Google Mail web interface even more useful. And of course, there's Google's superb search backing up all that email. If I were to bring email back from Google, I'd need to tackle the first of those two issues. (Search is largely a non-issue for me, as I very rarely keep my email, let alone search it.)

I've used Zimbra in the past, and could use a full-fledged collaboration suite, if I wanted to. I think things like Zimbra and Citadel and the like all scratch itches I don't have though. I mostly need email, and a decent calendar and contact manager. ownCloud offers the latter in a very nice package, so that would probably be my first stop.

It's been a long while since I last ran my own mail server, so I've got a lot of learning to do should I pursue this.

Ingress was a fun game, for a bit. Now it's not, at least for me. I'm just shy of reaching level 8, but I don't think I'm going to bother crossing that line. The game simply doesn't offer me anything in exchange for my time and effort.

Grinding

The game mechanics are pretty flat. The actions available to each player are the same for all players: there's no specialization, and no real strategy to the game:

1. Hack a portal
2. Attack resonators attached to enemy portals
3. Deploy resonators on unclaimed portals, or upgrade resonators on existing team-owned portals
4. Create control fields

Lather, rinse, repeat.

The game encourages team work by restricting the number of high-level resonators that can be deployed on any portal by a single player. A level 7 player can only deploy one level 7 resonator, for example. So in order to get a portal completely stocked with level 7 resonators, seven unique accounts are required to each deploy one level 7 resonator.

Griefers

Note that I said "unique accounts", as opposed to "unique players". There are a lot of people playing the game using multiple accounts. This is in direct violation of the Ingress terms of service, but it's a hard thing to police. So one human being could use two or three accounts to work together. This greatly improves their individual item inventories, and makes it much easier to tag-team enemy portals.

All games are going to have griefers. It's a fact of life. Whether they're violating the terms of service by using multiple accounts, or they're actively cheating by spoofing their GPS coordinates, there are a lot of ways to abuse Ingress. Folks like me who play by the rules are the losers. We don't level as quickly. We don't have as much access to inventory items.

Imbalance

One of the truly frustrating aspects of Ingress is that it take 8 unique accounts to build up a portal to level 7 or 8, but a single account can tear that down in a matter of minutes. So while (ostensibly) eight people need to coordinate their schedules to upgrade a portal together (synchronously or not), a single player of a lower level can come along at their leisure and undo all of that hard work.

Stalemate

There's no win condition to Ingress. You claim some portals, maybe make a field. The enemy comes along and blows up your portals, tears down your fields. They claim your portals, so you go blow up their stuff and reclaim them. This repeats forever. That's not particularly fun for me.

Unskilled

Indeed, there's no strategy for Ingress. Sure, you can argue about the relative value of where to place individual resonators, or when to make a field. But this is all academic: the enemy can and will destroy anything you create. The unending back-and-forth only rewards one specific kind of player: the one with ample free time.

I have a full-time job, and a family with which I enjoy spending time. I don't have the free time to constantly farm friendly portals for enough items to then make it possible for me to harass the opposition. There are a number of players on the opposing team who seem to have enormous amounts of free time. Ingress rewards them, and punishes me.

The lack of strategy means that all players are essentially equal. There's no specialization. Perhaps the game dynamic might be more interesting if different styles of play were rewarded. If there was some long-term in-game benefit to maintaining a control field, or recharging resonators, or something.

Social

The one really great thing to come from Ingress is that I've met -- virtually, and in real life -- a terrific group of players. The amount and quality of ad-hoc organization our team has performed is nothing short of amazing. I suspect the opposition does the same thing, though my personal experience with most members of the opposition has been less than friendly. That's unfortunate.

I don't know how long I'll remain in touch with the other players once I cease my involvement in the game. Participation in the larger community doesn't make much sense if I'm not playing the game. See also the bit above where I enumerate the restrictions on my free time: these restrictions also make it hard to attend team meetups.

In Conclusion

Lest this sound like a pity party for poor skippy, let me state unequivocally that the Ingress technology is really impressive. I hope Google / Niantic Labs learn from this and make a whole slew of other location-based games. I hope professional game designers take notice of what's happening, and work location-based gaming into new projects -- preferably ones with clear skill specialization opportunities, and less mindless grinding!

And for folks who still enjoy playing Ingress: good on yer! Keep playing. If this is the kind of game you enjoy, that's awesome. Getting out, learning about your town, and meeting new people are all awesome ancillary benefits that go along with Ingress.

It's just not the game for me.

Before Josie was born we set up a blog for her. The intent was for Angela and I to record Josie's early years in a fun way, without all the tedium of a traditional scrapbook. We wanted it to be low effort, high reward. We selected Posterous as the platform for Josie's blog, since it offered a decent product for zero cost and very little effort.

Posterous offered some great features for us: it supported dead-simple post-by-email and offered robust media management. The former meant that we could post to Josie's blog just about anywhere simply by firing off an email from our phones. Lots of other blog platforms support post-by-email, too, but Posterous's seemed to be so well baked in as to require no effort from us. Posterous also offers a decent -- though far from great -- application for both iOS and Android, so any kind of complicated post we might want to create could be done with that, too.

Where Posterous really shines, though, is media handling. Photos and videos attached to emails sent to Posterous show up automatically. No fussing with selecting sizes or transcoding videos. In the event that multiple photos are attached to a single post, Posterous generates a nifty little photo gallery automatically. It's super easy for us, the content creators, and extremely useful to all our family and friends who visit Josie's blog.

We'd been relatively happy with Posterous for the past two and a half years. But all good things come to an end. Two factors have driven me to migrate away from Posterous. Frist, Posterous was bought by Twitter. While Twitter hadn't mucked up Posterous much since the acquisition, they hadn't done much to make it a lot better than it was, either. Also, Posterous is shutting down. So there's that. The second big issue is that I finally realized that all our Posterous-hosted media lived off on its own, isolated from all the other media silos we use.

This last bit is the really important bit. I have a slowly growing collection of photos at Google, thanks to the confluence of Google+, Picasa, and Android Instant Upload. But I've also had a Flickr account since 2005, with more than nine thousand photos and videos. This represents the bulk of my digital life. To have another, separate, isolated repository of photos over at Posterous just didn't make sense.

Nor does it make sense to manually upload photos to both Flickr and Posterous. Sure, I could do something crazy with IFTTT, but that's just introducing more complexity by requiring that I create and maintain yet another account somewhere out in the cloud.

So I've spent the last couple of weeks updating the Habari post-by-email plugin to support pluggable storage mechanisms. I then wrote a Flickr storage plugin for PBEM that sends any email attachments to Flickr. This works a treat, thus far.

To make this all work, I've created a new email address for Josie's blog, and configured the PBEM plugin to check that account. Angela and I are whitelisted senders, so any emails we send to that account will appear as blog posts on Josie's blog. Any media attachments we include on our emails will be sent to Flickr, and embedded in the resultant post. This gives us all the benefits of Posterous with the added benefit that all of our photos and videos of Josie's life are part of my Flickr archive automatically.

I spent a couple hours on the OSU campus this afternoon. playing Ingress. There are a dozen or more portals within short distance from one another, so it's an easy place to build up some quick AP. I was able to earn 50K AP in a little over an hour, thanks to some help from Skyssx.

As we were wrapping up on the Oval, we saw some rings standing atop poles, and people running between them with sticks between their legs. It was the OSU Quidditch team! They were extremely friendly, and very eager to talk about the game.

I assumed it was a localized, fairly tongue-in-cheek event, but they told me they'd had tournaments in Indiana and Virginia, and a world tournament was scheduled for later in the year in Florida. Clearly this is a serious sport!

I captured a little of the action on video:

It actually looks quite fun!

I learned recently that the neighborhood high school will be participating in the US FIRST robotics competition. I've known about FIRST for a while, as one of the profs with whom I worked at OSU was a mentor for the organization, and had taken several teams to various competitions over the years. It didn't take me too long to decide to get involved.

The 2013 competition is called "Ultimate Ascent." The primary objective for the robots is to throw frisbees into various targets, thereby scoring points. At the end of the competition, robots can try to climb a pyramid, scoring more points the higher off the ground they can get. This last bit changes the robot design quite a bit: if a robot only has to throw frisbees, its design will necessarily be different than a robot that can climb.

There are about two dozen students on the team, with varying levels of interest and ability. The core team of active participants is about a dozen and these are divided into various working groups, each tackling a different aspect of the robot design. The team is planning to use a PandaBoard and one (or more) Playstation EyeToy cameras to detect the various goals. With my history of Linux, it was natural that I be assigned to the student working on this aspect of the robot.

Freddy, the student with whom I'm working, has some passing experience with Ubuntu. His laptop is dual-booting Windows and Ubuntu, and he'd made decent progress getting Ubuntu 11.04 installed onto an SD card for the PandaBoard. He had followed one set of instructions, but ran into problems configuring the OMAP4 add-ons. Watching over his shoulder, I asked him to start from the beginning, so that I could double check his work. He politely obliged, and we ended up at the same place: unable to install the OMAP4 add-ons. We tried yet again, this time using Ubuntu 12.04, with no more success.

"Well," I thought, "there's more than one way to skin a cat." So using Firefox I tired to browse the contents of the TI OMAP PPA to see if we could manually download the necessary files. This was met with an unhelpful message from the school's proxy informing me that the site I was trying to access was blocked. This proxy would end up causing all manner of trouble for us.

We had basically four options available to us:

1. try to use my phone as a mobile hotspot to bypass the proxy
2. try to install Ubuntu 12.10, which purported to not need the extra components from the PPA
3. try to install Fedora
4. take the board home to work on it without the interference of the proxy

Option #4 was clearly the option of last resort, as too many things could go wrong with the PandaBoard outside of the school. Option #3 was undesirable because Freddy was unfamiliar with Fedora and XFCE. We tried Option #1, but abandoned it when we didn't achieve immediate success. That left us with Option #2: install Ubuntu 12.10.

We now faced a new hurdle: there is no precompiled Ubuntu 12.10 image available to flash onto an SD card. Instead, we had to use the same install process as used by traditional desktops. This further meant that we couldn't easily install to the SD card that contained the boot image. Unfortunately, the PandaBoard only boots from the SD card, and not from USB. So we needed to flash the SD card with the install image, boot from that, and install to a USB stick.

All of that worked, but was exceedingly slow. Whether we used a slow USB stick, or the USB bus itself was slow, or some other factor was to blame, I don't know. But we realized that it was not going to be acceptable. The solution, thankfully, was extremely simple.

The PandaBoard uses a small 100MB FAT32 filesystem for its boot loader. The root image to load was defined in a simple text file on this partition. I simply repartitioned the SD card, leaving the DOS partition intact but creating two new partitions: one for an ext4 filesystem and one for a Linux swap partition. Using Freddy's laptop, we then copied the contents of the USB stick over to the new partition on the SD card. I edited /etc/fstab on the SD card's partition, updated the DOS partition's text file to point to the new partition, and that was it. The system booted Ubuntu 12.10 from the SD card without a hitch, and ran noticeably faster as well.

All of the above took several hours to complete, due to slow download speeds, lots of false starts, and a trip back home to fetch a USB stick of sufficient capacity. We decided to stop there, and would pick up the rest of the Ubuntu configuration the next time we met.

My biggest challenge through all of this was: how much do I let Freddy figure out for himself, and how much do I just do on my own to get it done. Clearly horsing around with Linux installation, partitions, and filesystems is not helpful to the overall construction of the robot; nor does knowing about any of this stuff help them win the competition. But at the same time, Freddy is clearly interested in the underlying technology and would benefit from a hands-on Linux education.

I decided to do most of the work, and explain as best I could what I was doing. Without a functional PandaBoard, much of the remainder of the robot construction was stalled, and we'd already taken a lot more time than I thought we'd need to get past our initial hurdles. Freddy was extremely patient and good humored about the whole thing. I didn't want to distract from the larger goal (ie: a working robot) with a bunch of yak shaving. Hopefully now that we have a functional Ubuntu installation, I can spend a little more time with Freddy on some of the more important Linux-based activities, and provide a more useful roadmap to Linux expertise for him.

Our next challenge will be to get the camera(s) connected and working, and to find how to identify the frisbee targets.