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
(which is often set up by default) or directly through '
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
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
/var/lib/smartmontools/drivedb/drivedb.h. Unsurprisingly, this
drive database is updated on a regular basis to add and correct
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
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,
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.)