Simplifying winter weather products

Decades after the National Weather Service began issuing watches and warnings, many members of the public don’t know what the difference is. When you throw in different products, the confusion only mounts. Too often, the products are based on meteorological distinctions that don’t necessarily mean much to the public. Take, for example, a nor’easter that struck New England in December. Or the confusion around the landfall of Sandy, which became extratropical shortly before landfall.

Some products you might see in a winter event include blizzard, winter storm, high wind, wind chill, ice storm, lake effect snow, and freezing rain. Plus flood products and special weather statements. How should the public try to understand these differences?

In general, I’m a proponent of getting the important information to the consumer as quickly as possible with minimal effort required. This case is an exception. Trying to cram the important information into the headline leads to public confusion and forces forecasters to spend time trying to decide which of a handful of products are correct instead of focusing on communicating impact.

I’m in favor of a smaller set of products, with specific impacts delineated in the text. A “winter storm” and “blizzard” product with watch, warning, and advisory (maybe) levels would go along way toward making the products more clear to the public. Everyone could spend less time thinking about the differences between the products and more time focusing on the impacts and preparedness.

If you’re interested in the official specification for the current suite of winter products, see http://www.nws.noaa.gov/directives/sym/pd01005013curr.pdf

Self-promotion is hard

I’ve never really written this blog with the intent of gaining a massive audience. Mostly, I don’t even notice if people read it or not. As much as anything, I write it as a way to document things for my own purpose or to express opinions that could never fit in a tweet. This is made plainly obvious by the fact that I almost never promote my posts. It’s fairly rare anymore that I even share them on my own social media feeds. I certainly don’t submit them to sites like Reddit.

This is partly because it feels like blog spam, and partly because I generally don’t think very highly of the posts I write. It’s way more rewarding when someone else sees a post and says “hey, that’s worth sharing.” Like my post about the PR blunder made by the elementary team. My friend Andy thought it was well-written and submitted it to /r/Linux. A little while later, it was at the top of that subreddit. Holy crap, I’m a real thought leader now!

A screen capture showing one of my posts at the top of the Linux subreddit.

Blog Fiasco at the top of /r/Linux

As of this writing, Andy has gained 622 link karma from the post. Karma that could have been mine, but I couldn’t bring myself to post my own blog. (Of course, I pretty rarely submit links anyway. My second-most karmatic submit is a Blog Fiasco post from three years ago. That’s the last time I self-submitted.)

Sometimes I think this pseudo-humility holds me back. I could probably gain more recognition in the field and achieve my dream of being a preeminent thought leader if I would just be more willing to force my writing on people. But that seems like a jerk move. So for the time being, I’ll just sit here and write in relative obscurity. If I get noticed and made into a star, that’s great. If not, well at least I’ll always have post 1652.

What’s in a (version) number?

Last week, Linus Torvalds posted a poll on Google+ asking people if the Linux kernel should continue with 3.x release numbers or if it was time for 4.0. I seem to recall Linus saying something to the effect of “it’s just a number” when Linux finally went from 2.6 to 3.0. Of course, it’s not just a number. Versions convey some kind of meaning, although the meaning isn’t always clear.

In general, I’m a fan of following the Semantic Versioning specification. In the projects I work on, both personally and professionally, I use something close to Semantic Versioning. I actually commented to coworkers the other day that I thought we had really screwed up on some product version numbers for not incrementing the major version when we made breaking changes.

But that’s the limitation of Semantic Versioning, too. Some projects do an excellent job of maintaining compatibility (for example, you can use some pretty old HTCondor versions with the new hotness and things generally work). Do they stick with the same major version forever and end up with very large minor versions? At some point, then, the major version becomes pretty useless.

A colleague remarked that in some cases, the patch number has become almost irrelevant. Back when even the smallest of releases meant mailing flopping disks or waiting an eternity for an FTP download, even patch releases where a big deal. In the modern era of broadband and web-based applications, version numbers themselves start to mean a lot less. If your browser auto-updates, do you even care what the version number is? Does anyone (including Facebook developers) know what version of Facebook you’re using?

Of course, not everything is auto-updating and even fewer things are web or mobile applications. Version numbers will be important in certain areas for the foreseeable future. It’s clear that no versioning scheme will be universally applicable. What’s important is that developers have a versioning scheme, that it’s made clear to users and downstream developers, and that they stick to it. That way, the version numbers mean something.

elementary misses the point

A recent post on the elementary blog about how they ask for payment on download created a bit of a stir this week. One particular sentence struck a nerve (it has since been removed from the post): “We want users to understand that they’re pretty much cheating the system when they choose not to pay for software.”

No, they aren’t. I understand that people want to get paid for their work. It’s only natural. Especially when you’d really like that work to be what puts food on the table and not something you do after you work a full week for someone else. I certainly don’t begrudge developers asking for money. I don’t even begrudge requiring payment before being able to download the software. The developers are absolutely right when they say “elementary is under no obligation to release our compiled operating system for free download.”

Getting paid for developing open source software is not antithetical to open source or free (libre) software principles. Neither the OSI’s Open Source Definition nor the Free Software Foundation’s Free Software Definition necessarily preclude a developer from charging for works. That most software that’s free-as-in-freedom is also free-as-in-beer is true, but irrelevant. Even elementary touts the gratis nature of their work on the front page (talk about mixed messages):

100% free, both in terms of pricing and licensing. But you're a cheater if you take the free option.

100% free, both in terms of pricing and licensing. But you’re a cheater if you take the free option.

Simply put, the developers cannot choose to offer their work for free and then get mad when people take them up on the offer. Worse, they cannot alienate their community by calling them cheaters. Of the money the elementary receives, how much of it goes upstream to the Linux Foundation, the FSF, and the numerous other projects that make elementary possible? Surely they wouldn’t be so hypocritical as to take the work of others for free?

An open source project is more than just coders. It’s more than just coders and funders. A truly healthy project of any appreciable size will have people who contribute in various ways: writing documentation; providing support on mailing lists, fora, etc.; triaging bug reports; filing bug reports; doing design; marketing (including word-of-mouth). This work is important to the project, too, and should be considered an in-kind form of payment.

It’s up to each project to decide what they want in return for the work put in. But it’s up to each project to accept that people will take from all of the choices that are available. If that includes “I get it for free”, then the right answer is to find ways for those people to become a part of the community and contribute how they can.

Upgrading users to new environments

Recently, Tom Limoncelli had a post at Everything Sysadmin describing how to move users to a corporate standard. Tom pretty much nailed it (particularly the part about the importance of management support), but I wanted to add my own experiences. Like Tom, I’ve been out of the fleet management business for a while. My perspective comes not from migrating from a wild west scenario to a standard, but from one standard to another.

As an aside, I was an undergraduate when my department left the wild west. The way computing worked on campus, this meant I was mostly unaware except for the weather lab and the one server that was my responsibility. I heard plenty of tales, though, from both the customer and provider side. I got to deal with the residual mistrust from all the things that went wrong. And I saw the graphs of ticket volume. Oh was it a mess I was glad to have missed.

For my part, the first summer after I became the department’s sysadmin, I decided it was time to upgrade the Linux machines. Our Linux servers were a mic of RHEL 3 and RHEL 4, while some of the desktops rand one of those or they ran Fedora Core 1. Fedora Core 1 was well beyond end-of-life by that point and packages for RHEL 3 and RHEL 4 were increasingly becoming out of date for the needs of the faculty and students who used them on a daily basis.

RHEL 5 had been released a few months prior, so it seemed like a good opportunity to get everything on the same OS. The first thing I did was to put a few spare machines in the computing lab as demo machines. Interested users could sit down and test the software packages they used and report any problems.

Meanwhile, I also surveyed each professor who had Linux machines or who taught in the lab about the software they used. Some packages we weren’t sure were ever used anymore, and it was a good opportunity to find cruft that could be cleaned up.

The next step was to “force” people to start using RHEL 5 machines by upgrading one machine in each lab (most of the faculty who had one Linux machine had several). Starting with the friendliest users, I hit every lab. We found a few problems here and there (a bug fix in tcsh caused on group quite a bit of trouble since they were inadvertently relying on the buggy behavior), but people could see them getting fixed.

The upgrade process got smoother the more times I did it, until we got to the point that I could sent our student employees off to get it started. The friendly users helped find the troublesome issues first so that the holdouts had a smooth experience. By the end of the summer all 70 or so machines were on the same OS, which reduced the support effort. Users had newer packages and a better experience. Everyone was happy and had cake (the cake was probably for something else, though).

The death of the adult snow day

Jesse Singal had a well-circulated article last week about the death of the adult snow day. As I write this post on a snowy Sunday afternoon, I can’t help but think he really nails it. Some of the commenters on the article focus on the snow day itself. In particular, “joy2b” wrote:

Playing in the snow is fun, but there’s really no need to spend all day doing it.  It should be possible to find a couple of opportunities to go out and play during a snow day.  If it isn’t, your typical work day is probably optimistically over-scheduled.

Isn’t that the point of the article, though? At least, that’s the message I took away. A little over a year and a half ago, I took a job where I was able to work from home on a daily basis. On the balance, it’s been good. I can eat lunch with my wife. I can do quick chores during the day. I can sit on the couch and keep an eye on my three year old daughter while my wife sleeps in. There are downsides, though. My family doesn’t always know when it’s okay to interrupt me and when it isn’t. Temper tantrums and crying babies sometimes carry on the phone. Worst of all, the line between working and not working has blurred.

This isn’t entirely due to working from home. I had a similar problem in previous jobs because work email didn’t stop arriving at closing time. In the past few months, I’ve begun disabling the sync on my phone outside of working hours. I’ve finally reached the point where I don’t end up manually checking it anyway. That has helped me immensely, but the line can still be a little blurry.

I never expected to say this, but there are times I miss my commute. Having a distinct time between work and home allowed me to shift gears and take a little bit of time to read a book or watch a few minutes of Netflix, or whatever. Now I go directly from work to home with no chance to make a smooth transition.

But back to the subject of snow days. When I worked at Purdue, snow days were pretty rare. After a particularly heavy snow storm in 2007, the university closed for a day and a half. I lived in an apartment then, so I didn’t have to worry about shoveling snow. My wife and I spent the time watching movies and having snowball fights with the upstairs neighbors. It was fun. Last winter, the university close again. This time, my former colleagues were expected to work from home. I don’t know that the University was any more productive than it would have been if the IT staff had been able to take the day off, but at least people weren’t getting paid to do nothing. Maybe that’s the reason the snow day is dying. But maybe that mindset is part of the problem.

NWS products are not ready for public consumption

Decades ago, dissemination of National Weather Service products was largely done via third parties, particularly broadcast media. Then along came the Internet and suddenly NWS products became readily available to the public at-large. This should have been a benefit, but the products have not adjusted to this new paradigm.

Forget that text products are still in all-caps (I’ve found that I have a harder time reading discussions that are in mixed case). Severe weather warnings give information out of order. Warnings and even regular forecasts suffer from discontinuity at forecast area boundaries. Worst of all, forecasts do not convey uncertainty, instead providing a single number instead of a possible range.

The snow storm that hit (to one degree or another) the east coast this weekend is an excellent example of how forecast uncertainty was not well-communicated. In some areas, the forecast was quite accurate. In others, snowfall predictions were far too high. The forecasters knew there was a high degree of uncertainty about the forecast, so why did the public and civic leaders?

It’s hard to fault individual forecasters. They work hard within the system to produce valuable forecasts for the American people. It’s the management and technology that prevent the message from getting out. In recent years, the industry (including the private sector) has begun to understand the need for social science to accompany meteorological science. Hopefully this new focus will help to make products for the modern public.

Introducing the “Permissive 3000″ license

Software licenses aren’t necessarily the easiest texts to understand. This issue is compounded when the person trying to understand the license is in a different jurisdiction or is a non-native speaker of English. A recent thread on the OSI’s license-discuss list brought this issue to light. According to the original poster, a project using the BSD 3-Clause license was used without attribution in a proprietary product. The developer lost the court case because the judge did not understand English well. The poster brought an attempt at a rewrite to the list, but it had some contradictions and other meaningful differences. So I thought I’d give it a try myself.

This weekend, I started from the original BSD 3-Clause license and excised all of the words not on the Oxford 3000™ word list (or reasonably close modifications, e.g. verb tense conjugations). I did make an exception for the word “copyright”, since it seems indispensable to a software license. In all other cases, I used synonyms and circumlocution in order to preserve the meaning while remaining within the constrained word list. This was challenging at times, since circumlocution can end up making the document more difficult to understand than an unknown word might. The difficulty is further compounded by the fact that many words have a distinct legal meaning and a synonym might not have the same weight.

I consoled myself with the fact that software warranties (where most of the real challenge was) are probably not that useful anyway. Furthermore, just because a word has a distinct meaning in American courts, that doesn’t mean that foreign legal systems have the same definitions. Trying to use largely U.S.-centric licenses written in English is a challenge for a global society, but I don’t know that a system of jurisdiction/language-specific licenses would be any better.

In any case, without further ado, I present the Permissive 3000 license. It’s highly experimental and totally unvetted by legal professionals, so nobody should use it for anything except a learning exercise. I’m looking forward to some constructive feedback and hopefully it sparks a discussion about how licenses can be simplified so that they’re more easily understood by judges, developers, and users alike.

Baseball and apple pie

Baseball isn’t as popular as it used to be. That’s hardly news. Some, including incoming Commissioner Rob Manfred, have argued that it’s too slow-paced for modern American society. To that end, he’s talking about some rule changes. The first is a “pitch clock”, designed to keep the game moving along. I don’t find that particularly objectionable, thought it would certainly take some getting used to.

The second, more obnoxious change, would be to ban defensive shifts. Seriously? If the idea is to generate more offense (it’s been a pitcher’s game since the end of the steroid era), my response is “who cares?” If you want to see a lot of hits, show up for batting practice. I’ll admit that I tend to be biased in favor of defense in sports. I’d much rather see a great dive and throw to first than a home run. If the shift is a problem, perhaps batters should learn to hit to the opposite field. I’m looking forward to Manfred proposing that players have to stand still until the ball hits the ground. Perhaps if he were the NFL commissioner, we’d finally see the “5-second count” rule for blitzes.

Next up for Rob Manfred: eliminating the apples from apple pie so people can eat it faster.

Using tracer to point out service restart needs

If you’re seeing this via Fedora Planet, you probably saw Miroslav Suchý’s post from a few days ago about a project called Tracer. Tracer is a friendly tool to tell you what outdated services are running. With the dnf plugin installed, you get a list at the end of the upgrade process.

For example, right after I installed the plugin and ran an upgrade, I was told that I needed to restart the Samba service. In addition, there were several programs that needed to be manually restarted (KeePassX and Spider Oak, to name two). Plus, one process required a logout, and one required a full system reboot.

I’ve found this to be pretty useful, since I don’t always realize what services need to be restarted after package updates. I have a decade of system administration experience, so it’s not too bad for me. For others, this is a great way to shine light on exactly what needs to be restarted and how.