Wireless spectrum versus the Internet

Last month, The Register reported on a new OpenWRT release. OpenWRT is a Linux distribution designed to be installed on embedded devices like routers. It, along with other third-party firmware projects like Tomato and DD-WRT, offers users more flexibility than the original firmware. They often get updates long after the first-party firmware, and can provide a more stable system. For example, I had a Linksys WRT-54G that was starting to get flaky, to the point where I had to power cycle it every day or so. After installing OpenWRT, it became much more reliable.

I lay out the benefits of third-party firmware, because the El Reg article brought to my attention a document published by the Federal Communications Commission (FCC). The guidelines, last updated in March of this year, outline the security questions device manufacturers should answer in their Part 15 application. Part 15 refers to the section of U.S. regulations that deals with unlicensed radio frequency (RF) transmission (including WiFi). The document says, in part:

An applicant must describe the overall security measures and systems that ensure that:

1. only properly authenticated software is loaded and operating the device; and
2. the device is not easily modified to operate with RF parameters outside of the authorization.

These requirements are antithetical to the ideals of open source and the user freedom it is committed to promote. As an amateur radio operator, I am sensitive to the concerns regarding spectrum pollution. Part 15 devices can be a pain for licensed portions of the RF spectrum anyway, and allowing devices to be easily modified to transmit outside their intended band presents a real threat to licensed radio services, including public safety and aviation.

Essentially, it comes down to protecting wireless spectrum (by preventing unlicensed transmission) versus protecting Internet users (by allowing for more security updates and external auditing of the code running on routers). These are both legitimate concerns, and I’d advocate for either of them independently. When they’re pitted against each other, though, I have to side with free software.

Regardless of the technological restrictions put in place to prevent unlicensed transmission, they can be circumvented. The entire history of technology is a history of restrictions and circumventions. Additionally, the ability to (responsibly) modify and experiment with hardware is an important part of innovation. The updates and configuration flexibility of third-party firmware provide a real benefit (though I naively assume that a non-trivial portion of devices will get such firmware) against everyday threats. Given the choice, my choice is clear. I hope the FCC will come to agree with me.

In defense of 140 characters

Re/Code reported Tuesday on rumors that Twitter is planning to change its hallmark 140-character limit. It appears that there are no firm plans, but there are a variety of ways this could change. The rise of the smartphone has diminished the importance of being able to fit a tweet into a single SMS message (at least in developed Western countries).

I’ve certainly been frustrated by the limit  at times. There have been thoughts left untwote because I couldn’t find a way to squeeze them into 140 characters. But I’ve also learned how to make my thoughts more concise. The need to edit forces me to consider what I’m saying and reduces the rash responses that I often give people in my head.

Is 140 characters the magic number? Probably not, but the immediacy that tweets provide probably offsets value that longer tweets would add. At some point, Twitter becomes Tumblr, and there’s already a Tumblr.

The experts say Twitter is looking to improve user and revenue numbers. I’m probably wrong, but I don’t see these changes being all that beneficial to either of those. Curbing abusive behavior and making quality content easier to find would go a lot further.

In the meantime, I’ll keep taking up whatever space Twitter gives me and hope it’s not too much.

HTCondor 8.3.8 in Fedora repos

It’s only been a month-plus since HTCondor 8.3.8 was released, but I finally have the Fedora packages updated. Along the way, I fixed a couple of outstanding bugs in the Fedora package. The builds are in the updates-testing repo, so test away!

As of right now, upstream plans to release HTCondor 8.5.0 early next week, so I got caught up just in time.

Hurricane Joaquin forecast contest begins

Hey! The tropics have awoken and there’s a not-unreasonable chance that the newly-upgraded Hurricane Joaquin will make landfall. Here’s your chance to test your forecast skill: http://funnelfiasco.com/cgi-bin/hurricane.cgi?cmd=view&year=2015&name=joaquin

Submit your forecast by 00 UTC on October 2 (8 PM EDT Thursday). If Joaquin does not make landfall, we’ll just pretend like this never happened. For previous forecast game results, see http://weather.funnelfiasco.com/tropical/game/

The ad-supported web

The history of the public Internet is a story of arms races. Spammers versus spam blockers. “Pirates” versus DRM. Websites against their visitors.

That last one might come as a surprise, but it’s an accurate-if-cynical description. Websites have content that visitors want, but the visitors (often) don’t want to pay and the website owners and contributors (often) want to make money for their work. Advertisements have become more and more obtrusive and visitors have worked harder and harder to keep those ads out of the way.

Fundamentally, the problem is that the Internet has changed the economics of information. It used to be that the value (economically-speaking) in reporting and commentary was the scarcity and the medium. As the Internet has democratized communication, the cost of an individual article gets much smaller.

Of course, the ability to get an individual article makes a difference, too. With a newspaper or magazine, you generally have to buy the whole thing. That’s not the case with websites. And advertisers in a newspaper or magazine can only do so much to get in your way. Perhaps technology just allows them to behave like they always wanted to.

In any case, Apple’s recent announcement that it would allow ad blockers on iOS has caused no shortage of consternation among content producers, especially on smaller sites and sites that depend solely or mostly on ad revenue. “Dear Apple: I may rob your store” is a fine example.

Everything is free! is probably not a sustainable model in the long term. By the same token, subscriptions for everything won’t work either. Micropayments are nice in theory, but I haven’t seen any evidence that they actually work. I don’t have an answer, since this isn’t really my area. I’ve made about four cents from my ads on Funnel Fiasco in the past 10 years, which is probably commensurate with the value I’ve provided.

The sky is not falling, but the landscape is changing. Old business models won’t continue to be viable. Some people will lose their jobs, some will find new niches to fill. I’ll continue to not use an ad blocker because I understand it’s the tradeoff for free content, but I’ll also continue to avoid websites that abuse my tolerance.

Too-detailed requirements?

Back in May, Scott Amber had a hot take:

This position is no surprise. In Ambler’s textbook, he advocates simple whiteboard sketches as the maximum level of modeling.

Why do so many project managers focus on so much documentation and process? In a lot of cases, it’s self-serving: tangible work output shows that they are doing something, which can be very important to compensation and continued employment. It also provides a sort of CYA in case the project fails.

Nonetheless, as Ambler suggests, too much is counter-productive. Time spent modeling and collecting requirements is time not spent on building the deliverable. Requirements that are too detailed up front reduce the flexibility needed as a project moves forward.

Ambler says the right detail level of requirements is “just enough”, which is an entirely unhelpful suggestion. In fact, I’d argue that it forces project managers to err on the side of being too detailed. For the reasons above, the incentive is to be more detailed rather than less detailed.

There are really two kinds of requirements: business and technical. The business requirements define what the end users need to be able to do (or not do), regulatory compliance, etc. These should be defined in terms of what, with no respect to how. For example, “the user should be able to remove jobs they submitted”, not “the user should be able to click the ‘Remove’ button on the ‘Jobs’ page to remove jobs they submitted.”

Now, it may turn out that the second example turns out to be exactly how it works, but why commit to that up front? Technical and UX expertise should define how the business requirements are implemented. That’s what your technical requirements are. Modeling and requirements will eventually get detailed as you iteratively develop the system. So detailed requirements are important (as documentation after the fact if nothing else), but the issue is when you get detailed.

ebooks versus dead tree books

For a long time, I avoided ebooks. Partly because reading on a monitor was just weird to me. Partly because I really like the feel and smell of physical books. Partly because having a dead tree version of manuals was important in outages. Partly because I don’t have to worry about DRM. Partly because I enjoy the look of a shelf full of books.

It wasn’t until my oldest child was born that I started getting into ebooks. The aspect ratio of my phone or tablet made long-form reading a lot easier than the “sideways” monitor setup. The real selling point was that the backlight was a lot easier to manage than a small reading light, particularly when trying to get a resistant child to fall asleep.

Still, my consumption habits are better suited for physical books. One of my favorite ways to get books is to peruse the discard shelf at the local library. I’ll pick up books that seem interesting. If they are, I’ll keep them. If they’re not, I’ll send them off to Goodwill. Digital media doesn’t (yet) have a similar paradigm.

On the one hand, that makes sense. Digital copies are cheap to the point of being basically free. Who needs to discard an ebook when you can just copy it? Of course, authors and publishers argue that such a model completely eliminates the commercial value of their work. I am very sympathetic to that, although there’s certainly room to make copyright law more consumer-friendly.

Slowly, I’ve begun adding to my ebook collection, generally when O’Reilly has their Day Against DRM sale. I’ll still prefer physical books for the most part, if nothing else because it’s easier to get them autographed. A conversion to more ebooks is probably inevitable, particularly once publishers realize that ebooks are cheaper to produce and adjust the prices downward accordingly.

Documentation formats and speaker interviews

In lieu of actual content on this blog, allow me to introduce you to some recent posts I’ve done for Opensource.com:

A changelog for the company?

"How to achieve Inbox Zero after the holidays" by CommitStrip. Used with permission.

“How to achieve Inbox Zero after the holidays” by CommitStrip. Used with permission.

A few weeks ago, Mathias Meyer shared an article that suggested a “Do Not Disturb” feature for Slack. At my job, Slack has become our main internal collaboration tool. It hasn’t quite killed email, but it’s pretty rare for members of the engineering team to send internal emails these days. It’s a great tool, but it can be hard to keep up with if you’re away for an extended period of time. This is particularly true when important messages get lost among jokes and gifs.

After being out of the office all of last week, I came back to several hundred emails and thousands of Slack messages. There was no way I could get through all of them, so I declared Slack bankruptcy (and deleted the emails that were for tickets someone else handled). I just have to trust that if there was anything important, my colleagues would fill me in. But is there a better way?

When I worked at McDonald’s, we had a management log book. It was a simple three-ring binder with hand-written notes. Mostly it was used by the store manager to communicate important information to shift managers and supervisors, but any of us could leave notes for things everyone on the management team needed to know. At the beginning of each shift, managers and supervisors were expected to read new entries and initial them.

I would go off to college for a semester and when I came back during breaks, the last few months of log entries were easy to catch up on. Obviously, they didn’t contain all of the changes, but at least I knew what the major changes were. It helped me come up to speed quickly, which was especially important when trying to lead teenage fast food workers.

I am a major proponent of work-life balance, both for myself, and for my team. It benefits neither the employee nor the employer to have people working all of the time. But it’s hard to fully disconnect when there’s a fear of missing out on important information. Perhaps a company changelog is in order?

This could capture important announcements, product decisions, unexpected lessons, and other things you really want team members to know. This allows people to declare bankruptcy when needed without missing key information. It doesn’t have to be anything fancy, a shared text file (in reverse chronological order) can be sufficient. Whatever works for your team.