When you make a Prometheus query in PromQL ,the result has both values and timestamps for those values (ascovered in the API documentation ).This is the case for both instant queries and range queries. Usuallytools ignore the timestamp on instant queries and use it to orderthe values for graphing or otherwise displaying the results ofranged queries.

(In Grafana , the timestamp is one of thefields you can display in a table. For reasons that we'll cover,the timestamp of typical queries is usually uninteresting

I recently read an article ( this one , via ) that advocated forjust using plaintext passwords inside TLS for things like IMAP and(authenticated) SMTP. My gut reaction was that this was a terribleidea in general, but I couldn't immediately come up with a solidreason why and why other alternatives are better for authentication.So here's an attempt.

There are (at least) two problems with passwords in general. The firstproblem is that people reuse passwords from one place to another, so

Suppose, not entirely hypothetically , that youhave some interesting metrics in your Prometheus system and you would like to get the rawtime series data points out of Prometheus. For example, supposethat you are seeing DNS resolution failures for Google domains(except not from Google's own 8.8.8.8 resolver), and you want toknow exactly when your Blackbox probes failed andsucceeded over some time range of interest.

Prometheus obviously has this data in its underlying time seriesdatabase (TSDB). Unfortunately

Today, I noticed something when I was in the office and mentionedit on Twitter :

I was going to ask why I have a Micropolis 4743NS hard drive sittingaround on my desk at work, but then I did a Google search on the modelnumber and uh I think I may have answered my own question: IndyDown

(It was actually on a side table, but you know how it goes withtweets.)

The Micropolis 4743NS is a 4.3 GB 'narrow

ARM support in Linux distributions demystified ( via ) isjust what it says in the title. Since I only just recently learnedabout things like 'Aarch64' in the process of writing this entry , all of this was timelyand useful. It definitely taught me things about ARM floating pointand architectures that I didn't already know.

( The discussion on lobste.rs hassome useful additional information about stuff.)

I recently read When The Text And Html Disagree ( via , itself via ), which isabout an instance where an email message had an important disagreementbetween the plaintext part and the HTML part. In this case it wasfortunately obvious that something was wrong, but I'm sure therehave been less obvious instances.

I believe that one reason this drift happens comes down to that oldaphorism that if you don't test it, it's broken. For email withalternate parts, the revised aphorism can

I've seen a variety of recommendations for safer shell scriptingthat use Bash and set its 'pipefail' option (for example, thisone from 2015 ).This is a good recommendation in one sense, but it exposes a conflict;this option works great for one usage pattern for pipes, andpotentially terribly for another one.

To understand the problem, let's start with what Bash's pipefail does.To quote the Bash manual :

The exit status of a pipeline is the exit

One of the reasons I've seen people put forward for respecting thenominal expiry dates of CA root certificates (and not having onesthat are too long) is that this is a way to deal with organizationalchange in Certificate Authorities, and in general in potential trustissues that come up over time. This idea feels natural, becauselimiting certificate lifetimes is certainly how we deal with a hostof trust issues around end TLS certificates (and why very limitedcertificate lifetimes are a good idea). The only practical way

One response to the idea that Certificate Authority root certificatesin your system's trust store should have their dates ignored(which is done in practice by some versions of Android andwhich you might put forward as a philosophical argument ) is to ask why CA rootcertificates even have dates in that case. Or to put it another way, ifCA root certificates have dates, shouldn't we respect them?

I think there are two levels of answers about why CA root certificateshave dates. The first level is that