It's getting colder and the virus is still spreading. Hundreds of thousands of people are dead. It's 399 years later, and Thanksgiving has changed less than you might have have hoped.

When the English arrived in what is now Massachusetts they found the Wampanoag devastated by smallpox:

The people not many, being dead and abundantly wasted in the late great mortality which fell in all these parts about three years before the coming of the English, wherein thousands of them died, they not being able to bury one another; their skulls and bones were found in many places lying still above ground, where their houses and dwellings had been; a very sad spectacle to behold.
  —Of Plymouth Plantation, Bradford.

Smallpox was still spreading, however, and later he writes (warning: gore):

HTTP offers a convenient way to download only the headers: send a HEAD request:

A group of round singers were interested in trying out the bucket brigade singing program, and I realized that with a small tweak it could support rounds directly. We just needed to write audio both at the place it belonged to, and an appropriate distance into the future. This would let everyone hear everyone else, though the leader still has to wait a bit before they start to hear others.

The system already needs to know BPM (beats per minute) so it can run a metronome, but the support around it also needs to know BPR (beats per repeat). For example, "Row, Row, Row, Your Boat" is a 16 beat round with participants entering every four beats, so you would probably set BPR to be 16. Four (or more) people could sing, with one person leading and each other person joining after the right number of beats as if they were singing together in person. Once everyone has been singing for 16 beats they all hear everyone else, and also themself.

You can get interesting effects by setting the BPR to some other multiple of the part interval, such as 12. This lets you sing along with yourself an offset, so that you appear to be one of the other singing voices.

It's also possible to configure the system with multiple repeats, so you would hear each iteration of your voice, say, three times. This can be fun if you have a small group of people and want to sing many parts, or even if you're playing around by yourself.

One thing this made me realize is that the latency calibration is really very important, and the previous way we were handling it was not sufficient. Originally, it started off trying to get a very accurate estimation of your latency, but if it wasn't doing very well it would slowly lower its standards. After about 30 seconds, it would let in people even with pretty inaccurate estimates. I've updated it now to be very careful, and if it can't estimate your latency to within 2 ms, it lets you know and gives you the choice between trying again, and joining without sending any of your audio to the server.

Feel free to play with it: echo.jefftk.com.

The Secular Solstice is planning on using the bucket brigade singing app that some friends and I have been building. While the events we've hosted so far have been something like 20 people, this might be 500 or more. I've spent some time over the last couple weeks figuring out how to scale it, and I think it's in a good place now.

I started, as one always should, with profiling. By far the biggest amount of time was being spent in Opus encoding and decoding. This is what lets us send audio over the internet at decent quality without using an enormous amount of bandwidth, so it's not optional. We're also already doing it in C (libopus with Python bindings) so this isn't a case where we can get large speedups by moving to a lower-level language.

The first question was, if we pulled off encoding and decoding into other processes, could we keep everything else in the same process?

In No Free Features, Alan Gibson writes:

I look forward to a day when asking anyone to do unpaid labor is considered unethical by our industry. That goes for feature requests on open source projects, on unpaid internships, and on unpaid 'take home' interview assignments.

Requesting work in an economic context without offering compensation in some form is morally indefensible. It's wrong because unpaid labor is wrong. It's wrong because presuming on anyone's helpful nature is wrong. We shouldn't be using bounties to move our change requests to the head of the line because we shouldn't even be making requests without a bounty attached.

This is an attempt to change open source norms, and I don't think it's a good one. While I'm sure there are some open source developers who see feature requests as a burden, lots of us just want to make useful software. If someone lets me know about a way that icdiff, or anything else I've written could be better, I'm happy to hear it.

I'm not always up for implementing changes, in which case I'll typically say whether a PR implementing the feature would be welcome. I set boundaries, and do only the work I want to do. I think some of this is an ask/guess (more) divide, where I would like people to feel free to ask for features, while Gibson would like people to only ask for features if they expect the request would be welcome (making up the difference with money if need be). Open source has traditionally been a very explicit ask-y place, however, and I think these norms have generally served the community well.

A little over four months ago I collected some data on how often people were wearing masks. Somerville still requires masks, cases are up, there is now a state-wide order, and I again found myself with some time during which I could take some notes. These numbers are not completely comparable: last time I tracked on a Sunday, this time a Saturday; last time I counted from 9:41am to 10:21am, this time 9:22am to 9:54am. Still, these should be pretty similar samples of behavior here.

I counted 130 people, but last time I didn't count babies and this time I did, by accident, which means that my number for children is no good. Looking just at adults, I counted 109 (vs 165) people of which 80% (87, +6pp) were masked, 9% (10, +4pp) had their nose exposed, 6% (7, -9pp) had their mask removed, and 5% (5, -1%) had no mask: