My Faults My Own (and other rossry.net and r-y.io subdomains) are now available over HTTPS, with certificates from Let's Encrypt. (cf. https://blog.rossry.net/https)

The setup took nontrivial effort, so I've narrated it here for my or your future reference. I don't think there's anything technically novel here, and there may even be an HTTPS-setup guide for 2019 somewhere else that dominates mine for usefulness, but there wasn't one easy-to-find enough that I found it, so here we are.

(0)

First, the dramatis personae:

Let's Encrypt (hereafter "LE"), a project of the nonprofit Internet Security Research Group, issues free TLS (née SSL) certificates; they recommend that site administrators with shell access use the LE client Certbot, a project of the Electronic Frontier Foundation.

My Faults My Own, and other rossry.net and r-y.io subdomain services, are happily hosted by Digital Ocean (this turns out not to matter), running nginx on Ubuntu 14.04. (Certbot supports many other servers and OS setups as

Amongst all of the large transitions happening in my life about now, I found it necessary to move my blog server from "some borrowed machine on the Harvard network" to a real-adult location, like "the cloud". After asking a few friends for recommendations, I decided to rent server time from Digital Ocean, at least as a stopgap measure until the end of the summer, when I'd be able to pick out my own internet plan.

I'm glad to report that I couldn't be happier with DO's service. Spinning up a new virtual server and migrating Faults to it was probably the easiest piece of system administration that I've done. I gave them my credit card number, told them that I wanted

From what I've seen as a TF for this course, it is very, very normal to write condition-variables code that looks like this:

struct cv {
    struct semaphore *sem;
    volatile int waiters;
}

void cv_wait(struct cv *cv, struct lock *lock) {
    KASSERT(lk_do_i_hold(lock));
    
    cv->waiters++;
    lk_release(lock);
    P(cv->sem);
    lk_acquire(lock);
}

void cv_broadcast(struct cv *cy struct lock *lock) {
    KASSERT(lk_do_i_hold(lock));
    
    for (; cv->waiters > 0; cv->waiters--)
        V(cv->sem);
}

This code is wrong (or, more specifically, badly synchronized). And it is such a common error that I'm choosing to dub it The Classic CV Error. It's subject to a race condition in e.g.

Why Do We Schedule, Master Bruce?

A scheduler, as you know, is responsible for determining which threads run, for how long, and in what order. As much as possible, it should give the shared illusion that each process is running constantly to completion, using the entire processor. To this end, there are three major desiderata:

• That interactive threads (in particular, user-interactive threads) are responsive.
• That no process starves.
• That the system, on average, runs quickly.

These high-level desiderata factor into the low-level conditions that:

• Threads which block expecting a response are rescheduled promptly after waking.
• Time is allocated more-or-less fairly, subject to:
• Processes closer to completion are prioritized (recall that shortest-time-to-completion-first is provably optimal in total