In this course, we will discuss classic papers across the broad area of Systems, in roughly chronological order by area: programming languages, architecture, runtime systems, operating systems, and system design in general. This is a lecture-driven class (not a seminar); you will not be expected to present papers, but you are expected to have read every paper before class and participate in in-class discussions.

This course can be used to satisfy core requirements for Systems for the M.S. and PhD degrees.

Grades will be based on in-class participation, projects, and exams.
You must submit your reviews via the review submission site the night before each class, by 9 p.m. Do not modify and re-submit your reviews: just submit once.

See these notes by John Ousterhout on writing reviews. Focus on the positive: these are classics for a reason!

Your reviews must address the following points:

• Summary: (at least two paragraphs) What is the problem that this work addressed? What are the big ideas / key insights / technical contributions?
• Significance / Contributions: How have the assumptions / context this work was based on changed? What is the practical significance of these results today?
• Discussion Points: Include at least two discussion points to bring up in class.

You will be expected to scribe at least one lecture’s notes. Here is an example to use as a template (in LaTeX).

below schedule is in flux. New papers to be discussed (not yet in schedule) include
* Spanner: Becoming a SQL System
* In Search of an Understandable Consensus (RAFT)
* SPECTRE / Meltdown papers
* Others TBD

NOTE: The use of laptops and cell phones is not allowed in class. Tentative paper reading schedule:

Plagiarism Policy

All projects in this course are to be done by you / your group. Violation will result in a zero on the project in question and initiation of the formal procedures of the University. We use an automated program and manual checks to correlate projects with each other and with prior solutions. At the same time, we encourage students to help each other learn the course material. As in most courses, there is a boundary separating these two situations. You may give or receive help on any of the concepts covered in lecture or discussion and on the specifics of programming language syntax.

You are allowed to consult with other students in the current class to help you understand the project specification (i.e. the problem definition). However, you may not collaborate in any way when constructing your solution: the solution to the project must be generated by you or your group working alone. You are not allowed to work out the programming details of the problems with anyone or to collaborate to the extent that your programs are identifiably similar. You are not allowed to look at or in any way derive advantage from the existence of project specifications or solutions prepared elsewhere.

If you have any questions as to what constitutes unacceptable collaboration, please talk to the instructor right away. You are expected to exercise reasonable precautions in protecting your own work. Don’t let other students borrow your account or computer, don’t leave your program in a publicly accessible directory, and take care when discarding printouts.