I recently wrote about when out crontab entries run , and in a comment Joseph asked ifwe'd considered switching toward systemd timer units instead. The shortanswer is no; the longer answer is that unlike Joseph's experience, wedon't think we'd find timer units to be a significant improvement overthe old, well understood crontab approach.

So let's start with the good things about systemd timer units ascompared to /etc/cron.d , which as I see it are two

It's clock change time tonight in Canada, so naturally when ourcrontab entries run is a little bit on my mind. This has led me torealize that almost all of our system crontab entries can be dividedinto two broad types.

The first sort of crontab entry is one that we want to run periodicallyat some interval (roughly, it doesn't have to be exact, especiallyfor the longer intervals). We have ones that run every minute, everyother minute, every five, ten,

In the past, I've said that one of our options for continuing to run Python 2 programs after Linuxdistributions stop packaging Python 2 at all is PyPy. As part ofthinking about this, I've found that PyPy starts fast enough forour Python 2 commands and I've surveyedLinux distributions to see what versions of PyPy they packaged (inlate 2020) . An implicit subtext of thelatter exercise, as with my periodic surveys of CPython versionson our Linux distribution, is that

I've come to think that there are two broad ways of viewing theworld that are used by most common version control systems. Althoughthe end result can be the same, these worldviews lead to differentplaces and can give people different attitudes, and I happen tothink that one is a better representation of reality than the other.

In the first worldview, the version control system manages snapshotsof a tree. When you make a new snapshot, you generally provide afreeform textual description of how it relates to one

Here is a simple seeming question you might wind up asking someday.Suppose that for some reason you need to keep encrypted copies ofyour backups. Does it matter if you use symmetric encryption forthis (where the encryption key is also the decryption key), or doyou need some form of asymmetric encryption (where the encryptionkey is not the decryption key)? Well, it depends on what yourthreats are (a threat model, in the jargon).

To start with, the difference between the two options

I recently wrote an entry on VCS history versus large open sourcedevelopment , where I arguedthat mostly requiring contributors to rebase their changes was asensible approach there. Recently this came up on Twitter and Isaid also that I used rebasing for carrying private changes ontop of upstream projects . So let'stalk about that.

If you carry private changes for an upstream repository, you havethree broad approaches. First, you can maintain your changes outsideof the VCS and "rebase" them when pulling upstream updates .

There is a general distinct dislike of Git's support for rebasing( cf ).I have some views on this in general ( eg ),but I feel that one overlooked thing may be that it's not uncommonfor people in certain situations to "rebase" changes when workingwith VCSes, whether or not they use Git and ' git rebase '. If youlook at rebasing changes as a conceptual operation instead of a Gitone, there are a number of ways that it happens and often VCSesthat

The traditional way I've looked at DMI and SMBIOS information is through dmidecode (eg to check RAM DIMMinformation ). I've done this interactively,and recently when I was inspired to automatically collect thisinformation and dump it into our metrics system , I also used dmidecode as the core of the script (and in the process, I discovered that vendors put peculiar things into there ). However, it turns out thatfor core DMI information you don't actually need dmidecode thesedays, because the Linux

In a comment on my entry on dealing with bad characters in stdin , Peter Donis said:

I've always thought it was a bad idea for Python 3 to make thestandard streams default to Unicode text instead of bytes. [...]

I'm sure this was a deliberate design choice on the part of thePython developers, but they tied their own hands so that it wouldhave been infeasible in early versions of Python 3 to make sys.stdin bytes instead of a Unicode stream. The problem