I recently discovered git worktrees and did some experimentation with using them for stuff that I do. The shortsummary of my experience so far is that while I can see the appealfor certain sorts of usage cases, I don't think git worktrees area good fit for my situation and I'm probably to use completelyindependent repositories in the future.

My usage case was building my own copies ofmultiple versions of some project, starting with Go . Especially in the case of a language compilerand its standard library

In theory, the literal text of a specification is the final authorityon defining what the specification means and requires. In practice,it generally doesn't work out this way; once a specification getsadopted, it ultimately becomes defined by its implementations.Regardless of what the actual text says, if everyone, or most people,or just dominant implementations do something or have some(mis-)interpretation of the specification, those things become thespecification in practice. If your implementation doesn't conformto the wrong

Pretty much every syndication feed format ever has some sort of'id' field for syndication feed entries (ie, the posts and so on)that is supposed to be unique for every entry in the feed and neverrepeat. Since basically everything else about a feed entry canchange (the title, the text, and yes even the URL), this unique IDis used by feed readers and other consumers of the syndication feedin order to tell the difference between new entries and ones thathave merely been updated.

In the old days, more or less all PC keyboards had a dedicated'Print Screen/Sysrq' key and using Linux's Magic Sysrq was easy: you held down Alt, PrintScrn/Sysrq, and an appropriatekey at the same time. However, this is becoming less and less commonall the time, and in particular my current keyboard doesn't have a dedicated Sysrqkey. Instead SysRq is overloaded on F9, and you get it by holdingthe keyboard's Fn key down when you

I was recently reading the JSON Feed version 1 specification (via Trivium , among other places).I have a number of opinions on it as a syndication feed format, butthat's not the subject of today's entry, because in the middle ofthe specification I ran into the following bit (which is specificallytalking about the elements of feed entries, ie posts):

• id (required, string) is unique for that item for that feed overtime. [...] Ideally, the

Yesterday I wrote a sober and respectable article on how usingthe GIL safely has various tricky traps and you probably shouldn'ttry to do it . This is indeed the sensible,pragmatic approach to exploiting what the GIL protects for threaded Python code; you probably don'tneed that much performance and so you should use some form ofexplicit locking instead of trying to be clever.

The honest truth is that I've exploited the GIL this way before andI'll probably write more Python code that does it

Recently I ran across Grok the GIL: How to write fast and thread-safePython ( via ),by A. Jesse Jiryu Davis . In the originalversion of the article, A. Jesse wrote:

Even though the line lst.sort() takes several steps, the sort call itself is a single bytecode, and thus there is no opportunity forthe thread to have the GIL seized from it during the call. We couldconclude that we don't need to lock around sort() .

In

When I first considered the use of a 'null MX' ,I was only thinking of it as a way of blocking email to hosts thatdon't get email (I had a special case that made some dedicatedspammer behavior unusually irritating). However,there is another useful case, and that's domains that don't send emailbut do get forged on spam.

A while back I wrote about a persistent phish spammer that consistently sends email using theforged sender email address of 'codewizard@approject

I'll start with my tweets :

A confession: I have a web site that uses jQuery. An old version ofjQuery, at that. It probably always will, because it works this way.

I could spend a bunch of time (as a non-JS-expert) to make my site usecurrent native browser APIs instead. But there's no payoff for us.

I've completely given up feeling guilty about still using jQuery andnot updating our jQuery versions. Our site is a tool