For our sins, we forward a certain amount of email to GMail (which isto say that it's sent to addresses here and then we send it onward toGMail). These days, GMail rejects a certain amount of that email atSMTP time with a message that some people will find very familiar:

550-5.7.26 This message does not have authentication information orfails to pass authentication checks (SPF or DKIM). [...]

(They helpfully include a

We are not anywhere near ableeding edge environment. We still mostly use 1G networking, with10G to a minority of machines, and a mixture of mostly SATA SSDswith some HDDs for storage. A few very recent machines have NVMedisks as their system disks. So here are the speeds that we see andthat I think of as 'normal', here in mid 2022 in our environment,with somewhat of a focus on where the limiting factors are.

On 1G connections,

I tweeted :

I didn't expect these spinning rust HDs to be able to sustain 235Mbyte/sec read and write rates (sequential IO, it's software RAIDbuilding/resynching). I guess large, high-density drives have improvedthe 150 MB/sec I used to expect.

I haven't paid attention to the spinning rust hard drive industry fora while (long enough that I missed the terminology switch from 'HD' to' HDD '). Generally at

A number of years ago I wrote about what influences SSH's bulktransfer speeds , and in 2009 I wrote what turned outto be an incomplete entry on how fast various ssh ciphers were on the hardware of the time. Today, for reasons outsidethe scope of this entry, I'm interested in the sort of best caseperformance we can get on good modern hardware, partly because weactually have some good modern hardware for once. Specifically, wehave two powerful dual-socket systems,

Recently I was looking at files that contained a bunch of sizes inbytes with very widely varying magnitudes, something like this:

file 10361909248percpu 315360inactive_file 8666644480active_file 1695264768slab_reclaimable 194324760slab 194324760[...]

(This is from

Every so often I think about the issue of what our eventual Python2 endgame is going to be at work .We're going to reach some sort of endgame situation sooner or later;for example, Ubuntu has already removed support for /usr/bin/pythonbeing Python 2, although you can still do it by hand. Someday they(and other people) may mandate that /usr/bin/python is Python 3, orremove Python 2 packages entirely, or both. What are we going to

Recently I was looking at a panel in one of our Grafana dashboards and noticed that its PromQL queriesused avg_over_time() when it (now) felt as if max_over_time()was what the panel should be using. It's been years since I createdthis panel and last touched it, and I definitely no longer rememberwhat I was thinking at the time. Did I have a good reason thatavg_over_time() was necessary, or did an average

Linux distributions that use systemd probably have cgroup memory accounting turned on (this is system.conf's DefaultMemoryAccounting ,which defaulted to on starting in systemd 238). Memory accountingis handy because it will give you a hierarchical per-cgroup breakdownof memory usage for your services, user sessions, scopes, and soon, which you can see with tools like systemd-cgtop orperhaps your own tools .However if you look at this you can get some surprises, such as a virtualmachine that you

Suppose that you build a Go program on one Linux machine, copy it to asecond one, run it on that second machine, and get an error message likethis:

./dlv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./dlv)./dlv: /lib/x86_64-linux-gnu/libc.so.6: