Wandering Thoughts archives

Companies and their stewardship of open source projects

One of the articles of the time interval is Dustin Moris Gorski's Can we trust Microsoft with Open Source?, written in the wake of what I will just describe as Microsoft shenanigans around .NET. In the wake of reading that and having some general thoughts, I tweeted:

Can we trust Microsoft with open source? No, of course not. Nor can we trust Google, Apple, or Facebook. Any appearance of open source friendliness is tactical; it's not and has never been a deep seated cultural value.

(Applications to Github are left for Halloween scares.)

All of these companies (and others) have behaved in less than desirable ways around open source projects that they have either founded, inherited, or become significant contributors to (whether that contribution is developer resources, money, or what have you). And these are the good companies, the ones where the issue is even worth talking about.

(Oracle closing off OpenSolaris is very well known, but no one expects anything from Oracle except rapacious pricing.)

As a good first approximation, we cannot expect any company to be a genuinely good steward of open source projects. Unless open source is extremely deep in the company's culture, their support of open source is not a core imperative, it's a cold blooded business decision. This doesn't necessarily mean that they are exploiting open source, but it does mean that their support for their open source projects will only continue as long as they consider it not harmful and not too expensive for the benefit that both the project and being good stewards bring them. As we saw with .NET, when this is no longer true, things happen.

(Microsoft backed down this time but that was because their calculus of costs and benefits changed, not because they had a change of heart. The future course of Microsoft's stewardship of .NET is now clear, if it wasn't already.)

I do think that large companies can make what they feel is a good faith decision today to be a good steward to some open source project. Companies are made up of people and people can have good intentions and take actions with them. But companies also respond to incentives (and indeed are forced to), and over the long run those incentives point in the wrong direction. By default, a company is a remorseless machine that will crush any significant obstacle in its path.

Your SMART drive database of attribute meanings needs regular updates

A lot of people use the smartmontools tools to monitor their drives, either automatically through smartd (which is often set up by default) or directly through 'smartctl'. If you've ever used 'smartctl -A' to get the SMART attributes of your drives, you know that these attributes have names that often give you important information on how to interpret their values. Sadly, these names (and measurement units) mostly aren't standardized; instead, drive vendors come up with whatever they want, including varying them from model to model. Even when they use the same SMART attributes for the same purpose as other drives they may change the units.

Smartmontools deals with this by having a text file that contains a bunch of mappings for what various SMART attribute IDs mean on various different drives. On many systems, you can see your current version of this database in /usr/share/smartmontools/drivedb.h or /var/lib/smartmontools/drivedb/drivedb.h. Unsurprisingly, this drive database is updated on a regular basis to add and correct entries.

A SMART database that's missing necessary entries for your disks can have two effects. The obvious effect is if some SMART attributes are called just 'Unknown Attribute'; this at least lets you know that you don't really know what's going on. More dangerously, some attributes might be mis-labeled, so that for example smartctl thinks that the attribute is 'Total LBAs Written' when it's actually 'Host Writes GiB' (which explains why the values we see are so low on that disk model).

If you're using a Linux distribution that makes frequent releases, your smartmontools probably has a pretty up to date version of the drive database. If you're using a less frequently updated distribution, for example Ubuntu LTS, your SMART drive database is going to be out of date almost as soon as the distribution is released. This generally means that you want to update your drive database on a regular basis, unless you only ever use drives that are sufficiently old that they're in a SMART database from, say, 2018 (spoiler, they're not).

Smartmontools ships with an update-smart-drivedb script that can be used to do this. By default, it updates the location that was built into distribution package, which you may not want to do. Fortunately you can tell it to fetch to some other location, which you can then tell smartctl to use with 'smartctl -B ....'. You can also just read the script to determine the URLs and then fetch one of them yourself. I've generally used the smartmontools Github repo since I find the web interface much easier than SVN. You want drivedb.h in raw format, possibly from a branch instead of trunk.

(We've used the trunk version of drivedb.h without problems so far. Well, without obvious and visible problems at least.)