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).

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.

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.

On Linus Torvalds and communities

This week, the Internet was ablaze with reactions to comments made by Linus Torvalds at Linux.conf.au. Unsurprisingly, Torvalds defended the tone he employs on the Linux kernel mailing list, where he holds no punches. “I’m not a nice person, and I don’t care about you. I care about the technology and the kernel—that’s what’s important to me,” he said (as reported by Ars Technica). He later said “all that [diversity] stuff is just details and not really important.”

The reactions were mixed. Some were upset at the fact that an influential figure like Torvalds didn’t take the opportunity to address what they see as a major issue in the Linux community. Others dismissed those who were upset by pointing to the technical quality of Linux, cultural differences, etc.

I don’t subscribe to the LKML, so most of the posts I’ve seen are generally when someone is trying to point out a specific event (whether a behavior or a technical discussion), and I don’t claim to have a good sense for what that particular mailing list is like. Torvalds and the Linux community have developed a great technical product, but the community needs work.

Speaking to open source communities in general, too many people use the impersonal nature of email to mistake rudeness for directness. Direct and honest technical criticisms are a vital part of any collaborative development. Insults and viciousness are not. Some people thrive in (or at least tolerate) those kinds of environments, but they are incredibly off-putting to everyone else, particularly newcomers.

Open source communities, like any community, need to be welcoming to new members. This allows for the infusion of new ideas and new perspectives: some of which will be obnoxiously naive, some of which will be positively transformative. The naive posts of newcomers can be taxing when you’ve seen the same thing hundreds of times, but everyone has to learn somewhere. The solution is to have a team armed with pre-written responses in order to prevent frustrated emails.

Not being a jerk doesn’t just mean tolerating noobs, though. Communities should have an established code of conduct which addresses both annoying and mean actors. When the code of contact is being repeatedly breached, the violator needs to be nudged in the right direction. When a community is welcoming and actively works to remain that way, it thrives. That’s how it can get the diversity of ideas and grow the technical competency that Linus Torvalds so desires.

A lesson in ISO weeks

Last week, users of the Twitter client for Android experienced authentication problems. It was a long and lonely Sunday night for me without my Tweeps. When the issue was fixed, word on the street was that it was due to time travel, in a sense. Sunday started the first week of 2015 if you’re using ISO week numbering.

The next morning, I got my regular weekly email from our time tracking system at work, except it showed I had recorded zero hours in the previous week. Late December tends to be a quiet time, but not that quiet. Then I looked a little closer and noticed that the email was for week 2015-52. Oops!

I thought I’d take a look at the code for the report generator, and my hunch that it was also an ISO week issue was quickly confirmed. In the code, the current date was recorded and split into year and week values. Then the week value was decremented. This seemed silly to me. I changed it to first subtract a week before splitting into the year and week values. This seemed to fix…the glitch.

So what’s the lesson in all of this? First, make sure you do the math at the right time. Secondly, make sure you understand how time works. The year of the ISO week being ahead of the calendar year only happens on limited occasion. It’s not a scenario that one would think to test (though I expect a lot more tests will include it now).

Computer stuck at “Verifying DMI Pool Data”

I built my desktop back in 2009 and it has served me well. However, I decided that a dual-core machine with 4 GB of RAM just really wasn’t cutting it in 2015. Flush with Christmas cash, I upgraded to an eight-core CPU and 16 GB of RAM. This also meant bringing a new motherboard along for a ride. Like my old motherboard, this new one was a Gigabyte product (GA-78LMT-S2P, specifically), so I figured life would be pretty simple.

After work, I yanked the old parts out and inserted the new. I booted the new machine and made sure the BIOS settings were just how I wanted them. I let it boot and…

Crap. It got stuck at “Verifying DMI Pool Data”. For a long time. I did some searching and most of the answers I found suggested that the answer was one of a bad SATA cable, a bad SATA port, or a bad disk. None of these seemed to be the case, as the RAID utility found all four drives. But wait, I have five. Two smaller drives in a RAID 1 for my OS and local files, and a 3×1 TB (software) RAID 5 for data.

Therein lies the solution: by setting SATA ports 4/5 to RAID instead of IDE mode, the computer booted right up. I leave this here as a marker for anyone else who happens to come across this problem (or myself if I repeat it in another six years). As an aside, this is the first time I’ve played with hardware in a few years. I kind of missed it a little, tiny bit.

In defense of the bazaar

Earlier this week, I came across a 2012 article from Poul-Henning Kamp entitled “A generation lost in the bazaar“. This is a reference to Eric S. Raymond’s seminal The Cathedral and the Bazaar, which advocates for making the sausage, so to speak, in public. Using the Linux kernel and his own fetchmail program as examples, Raymond emphasizes the benefits of rapid, iterative development and of fostering a user community that acts as co-developers. This stands in contrast to the “cathedral” style of development where a product is worked on by a small number of people until it is ready to be revealed to the public.

Kamp’s point (and subtitle) is “quality happens only when someone is responsible for it,” which I endorse wholeheartedly. However, he is mistaken to blame Raymond’s bazaar for “a clueless generation of IT ‘professionals’ who wouldn’t recognize sound IT architecture if you hit them over the head with it.” What he observes is the democratization of programming, which is due to ever-cheaper hardware, free (as in beer) software, and the Internet. Had The Cathedral and the Bazaar never been written I doubt the world would look dramatically different, at least in this respect.

IT is in its awkward teenage years. It has been around long enough that it can do pretty cool things, but not so long that it has accumulated much wisdom. The fact that anyone can write software (or copypasta snippets from various example sites and fora) and make it available to others is simultaneously a wonderful and terrible thing. Nonetheless, that doesn’t make the bazaar style wrong.

Kamp described the end result of the bazaar as “a pile of old festering hacks,” and I’ll agree that its an apt description for a lot of software. It’s probably just as apt for a lot of software developed in the cathedral style. Raymond devotes a fair portion of his book to quality and good design, and it’s unfair to blame him for people not following that part (assuming they’re even aware of his work at all).

Raymond makes many unsubstantiated claims that the bazaar style of development leads to higher-quality software. That may or may not be the case. My own view is that the bazaar style is well-suited for open source projects. After all, open source is about more than code.

Another great SysAdvent

Once again, a group of volunteer writers and editors came together to put together 25 posts related to systems administration for the SysAdvent blog. Although I have contributed several articles over the years, I much prefer editing. All of this year’s posts are great, but I’m very proud of the posts that I had a hand in editing. As usual, the writers did most of the work, my suggestions were always minor.