Selma teaches us, too, that action requires that we shed our cynicism. For when it comes to the pursuit of justice, we can afford neither complacency nor despair.

Just this week, I was asked whether I thought the Department of Justice's Ferguson report shows that, with respect to race, little has changed in this country. I understand the question, for the report's narrative was woefully familiar. It evoked the kind of abuse and disregard for citizens that spawned the Civil Rights Movement. But I rejected the notion that nothing's changed. What happened in Ferguson may not be unique, but it's no longer endemic, or sanctioned by law and custom; and before the Civil Rights Movement, it most surely was.

We do a disservice to the cause of justice by intimating that bias and discrimination are immutable, or that racial division is inherent to America. If you think nothing's changed in the past fifty years, ask somebody who lived through the Selma or Chicago or L.A. of the Fifties. Ask the female CEO who once might have been assigned to the secretarial pool if nothing's changed. Ask your gay friend if it's easier to be out and proud in America now than it was thirty years ago. To deny this progress -- our progress -- would be to rob us of our own agency; our responsibility to do what we can to make America better.

Of course, a more common mistake is to suggest that racism is banished, that the work that drew men and women to Selma is complete, and that whatever racial tensions remain are a consequence of those seeking to play the "race card" for

"Jury Selected in Boston Marathon Bombing Trial", reports The Crimson today. I don't care.

I am so far beyond caring about where Dzhokhar Tsarnaev ends up that I'm refusing to click on that link, and won't give you a hyperlink here; feel free to search it up on your own, if you like. I am aggressively refusing to care.

Or at least, aggressively refusing to indulge in anything that would incite me to care more than I can possibly avoid.

I mean, look, you can hate the kid. You can meditate on the violence he perpetrated against the city of Boston and the fear that he and his brother struck across our city for days, plural, of 2013. You can follow the news of his trial, conviction, and imprisonment with a carefully-stoked bloodthirst, and feel a measure of closure on behalf of our city when he gets put away for life without parole, or executed.^[1] You can live a life where every time you're reminded of him or his brother, you indulge in the feeling of rising rage. I understand too well how close this thing cut to tell you not to do that, because, really, I understand.

But I won't. Quoth Pratchett:

"But we should kill him!"

"No. You've been listen to Brocando too often," said Bane.

Brocando bristled. "You know what he is! Why not kill--" he began, but he was interrupted.

"Because it doesn't matter what he is. It matters what we are."

I'm never going to see Dzhokhar, and I'll never have any sort of human interaction

James Mickens is speaking at the Harvard CS Colloqium at 4pm today in Maxwell-Dworkin, which is amazing because James Mickens is amazing because James Mickens is the author of "The Night Watch":

As a highly trained academic researcher, I spend a lot of time trying to advance the frontiers of human knowledge. However, as someone who was born in the South, I secretly believe that true progress is a fantasy, and that I need to prepare for the end times, and for the chickens coming home to roost, and fast zombies, and slow zombies, and the polite zombies who say “sir” and “ma’am” but then try to eat your brain to acquire your skills. When the revolution comes, I need to be prepared; thus, in the quiet moments, when I’m not producing incredible scientific breakthroughs, I think about what I’ll do when the weather forecast inevitably becomes RIVERS OF BLOOD ALL DAY EVERY DAY. The main thing that I ponder is who will be in my gang, because the likelihood of post-apocalyptic survival is directly related to the size and quality of your rag-tag group of associates. There are some obvious people who I’ll need to recruit: a locksmith (to open doors); a demolitions expert (for when the locksmith has run out of ideas); and a person who can procure, train, and then throw snakes at my enemies (because, in a world without hope, snake throwing is a reasonable way to resolve disputes). All of these people will play a role in my ultimate success as a dystopian warlord philosopher. However, the most important person in my gang will be a systems programmer. A

The internet is a great and terrible thing. I say this often. We are inundated with a dramatically larger \(N\) of events to process and, thanks to social media, a larger audience to say it to.

I don't claim that the UC does a good thing by spouting largely empty declarations of support. I agree that it's trivializing, condescending, and mostly devoid of meaning, particularly when we seem to stand in solidarity with every cause that comes our way to demonstrate that we are caring, compassionate, and informed citizens of this world. I remember back in April when the #bringbackourgirls hashtag in support of the kidnapped Nigerian schoolgirls exploded on Twitter--for two days. We offer our solidarity when it is easy, convenient, and painless, and move on with our lives.

All the same, I think there is something valuable in the exercise of directing attention to events, causes, and ideas that otherwise would have slipped our notice. How many of us would have noticed, much less bothered to care for 30 seconds or 5 minutes, the shootings at UNC had they not blown up our social media newsfeeds? Maybe I am being cynical and underestimating my peers when I say probably very few. We notice because someone tells us to; we forget when the next new thing crowds for our attention.

So in some senses, sure. The UC does not stand in solidarity, the UC does not think carefully about what it means to be a Muslim in the United States or

(0)

Context: The Crimson | UC Passes Act of Solidarity in Light of UNC Shooting. But first, Scott Alexander writing in Slate Star Codex | I Can Tolerate Anything Except the Outgroup (himself quoting Chesterton):

There are a lot of people who say "I forgive you" when they mean "No harm done", and a lot of people who say "That was unforgiveable" when they mean "That was genuinely really bad". Whether or not forgiveness is right is a complicated topic I do not want to get in here. But since forgiveness is generally considered a virtue, and one that many want credit for having, I think it's fair to say you only earn the right to call yourself 'forgiving' if you forgive things that genuinely hurt you.

To borrow Chesterton's example, if you think divorce is a-ok, then you don't get to "forgive" people their divorces, you merely ignore them. Someone who thinks divorce is abhorrent can "forgive" divorce. You can forgive theft, or murder, or tax evasion, or something you find abhorrent.

I mean, from a utilitarian point of view, you are still doing the correct action of not giving people grief because they're a divorcee. You can have all the Utility Points you want. All I'm saying is that if you "forgive" something you don't care about, you don't earn any Virtue Points.

(1)

Sunday, The Crimson reports (edit: ...and the UC finally gets around to publishing), the Harvard

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. the following case:

int before_and_after (int *the_thing, struct cv *thing_changed_cv, struct lock *thing_changed_lock) {
    lk_acquire(thing_changed_lock);
    
    int before = *the_thing;
    cv_wait(thing_changed_cv, thing_changed_lock);
    int after = *the_thing;
    
    KASSERT(before != after);
    
    lk_release(thing_changed_lock);
    return compare_things(before,after);
}

void mess_around (int *the_thing, struct cv *thing_changed_cv, struct lock *thing_changed_lock) {
    lk_acquire(thing_changed_lock);
    mutate(the_thing);
    
    cv_broadcast(thing_changed_cv, thing_changed_lock);
    
    lk_release(thing_changed_lock);
}

This code is properly synchronized (and in particular, protects the KASSERT(before != after)), assuming that your locks and CVs

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 average time)
• ...but in any case, do not starve even the long-running processes too much (exponentially is a good benchmark -- since that, analytically, places a finite cap on the total runlength of a process).

Many of the designs I've seen from the class in A2 design documents fail in at least one of these respects, so I think it may be useful to go over common design failures and good designs.

indicates a potential issue of which you should be cautious. Check that your system doesn't have this as an issue!

Timeslicing and Timedicing

Not every thread blocks voluntarily; after running a thread for a certain