COMPSCI 110
Introduction to Operating Systems
Spring 2007

Goals of the Course

To cover the traditional topics: What is an Operating System and what is it supposed to do for us? How does it accomplish these functions? How are such systems implemented and structured? Topics include concepts of protected kernels, processes and threads, concurrency and synchronizations, file systems, and virtual memory.

To help you develop new skills: Concurrent programming. Inheriting large, complex software systems and adding value (as in the "real world"). Developing an intuition for system design tradeoffs. A major component of the course is a series of implementation projects.

To give you occasional glimpses into current Operating Systems research, motivated by hardware trends, web applications, and mobile computing.

Who should take this course? All undergraduate CS majors should take this course at some point. You should have completed the basic introductory sequence, and also CPS 104.

Workload. This is a demanding course. There are 3 required programming assignments. To make things a bit easier, you will work in teams of (generally) 3 students. In addition to the programming assignments, there will be problem sets, an in-class midterm exam, and an in-class final exam.

Textbooks and Other Resources

Modern Operating Systems, 2nd edition, by Andrew Tanenbaum

All course materials, lecture slides, and announcements will be accessible via the course web site at http://www.cs.duke.edu/courses/spring07/cps110. You will visit this web site often, as we will rarely hand out printed materials in class.

There is also a course newsgroup. We prefer that you post questions to the newsgroup rather than e-mailing us. We read the newsgroup regularly, and so should you: it is embarrassing to ask a question or waste time struggling with a problem that has already been discussed in the newsgroup. If you know the answer to a posted question, please post a response. Let's make this class into a community for learning.

Grading

As your instructor, I see my role as that of coming up with exciting and valuable learning activities for you to do and I consider establishing a grade in the course by evaluating the results of those valuable learning activities as just a side-effect. Still, I bet you are interested in how these activities factor into your grade, so here is the breakdown (approximate -- your mileage may vary):

• Programming projects (45%). Hands-on experience that will develop skills and give you an in-depth appreciation for some of the details and concrete design issues.
• Exams - one midterm (20%) and final (30%).
• Course participation (5%). This category catches many activities: (1) problem sets in discussion sessions will involve the solution of problems based on the textbook readings. The problem sets are uncorrected, but will be collected and recorded. You should make a good faith effort to work on the assigned problem set prior to the meeting of the discussion session to make it more meaningful and interactive. This will allow the discussions to talk about alternative solution techniques and to go beyond the scope of the assigned problems. The purpose of the readings and homework is to fill in the breadth that the specific programming projects can not address. These problems will also give you a very valuable preview into the content and style of the exams. Many of the exam questions will be drawn either directly from the problem sets or be very similar. (2) If class attendence becomes an issue, I do not rule out the possibility of pop quizzes for some of these points. (3) I would like this to be an interactive class, so I expect you to ask questions and offer ideas freely.

I grade on a curve to compensate for any possible problems with the projects and exams.

Policies & Advice

The Reasonable Person Principle

This principle (which applies throughout this course) simply states that a reasonable request made in a reasonable fashion shall be reasonably handled by reasonable persons. The TAs and instructor are reasonable people, and we expect that everyone else involved in this class is as well. Asking to be a special case to turn stuff in late is not a reasonable request, barring extreme circumstances.

Collaboration vs. Cheating

Collaboration is a very good thing. Students are encouraged to work together and some programming projects will require a team effort with everyone expected to contribute.

On the other hand, cheating is considered a very serious offense. Please don't do it! Concern about cheating creates an unpleasant environment for everyone. Obvious forms of cheating include getting solutions from the web or from former students of previous semesters and acquiring code segments from other groups in this class.

So how do you draw the line between collaboration and cheating? Here's a reasonable set of groundrules. Failure to understand and follow these rules will constitute cheating, and will be dealt with as per university guidelines.

1. The Gilligan's Island Rule: This rule says that you are free to meet with fellow students(s), study for exams together, and discuss assignments with them. Writing on a board or shared piece of paper is acceptable during the meeting; however, you should not take any written (electronic or otherwise) record away from the meeting that could later be used for what is supposed to be an individual effort. After the meeting, engage in a half hour of mind-numbing activity (like watching an episode of Gilligan's Island), before starting to work on the assignment. This will assure that you are able to reconstruct what you learned from the meeting, by yourself, using your own brain. Similarly, each student in a group should be able to explain and justify their group's approach to the programming projects. This means understanding the pieces other group members have written well enough to explain it (again, after an episode of Gilligan's Island) without relying on them to do it.
2. The Freedom of Information Rule: To assure that all collaboration is on the level, you must always give the name(s) of your collaborators or sources (e.g. the web) on your assignment. Failure to adequately acknowledge your contributors is at best a lapse of professional etiquette, and at worst it is plagiarism. Plagiarism is a form of cheating.
3. The No-Sponge Rule: In intra-team collaboration where the group, as a whole, produces a single "product", each member of the team must actively contribute. Members of the group have the responsibility (1) to not tolerate anyone who is putting forth no effort (being a sponge) and (2) to not let anyone who is making a good faith effort "fall through a crack" (to help weaker team members come up to speed so they can contribute).

Choose your partners well. You should discuss prior experience of potential group members and schedules before agreeing to form a group. One of the greatest difficulties is in groups that can find no common times in their schedules for working on projects together. You should also talk about working styles and communication within the group.

Dealing with Dysfunctional Group Situations

Every year, there is at least one group that fails to develop a working relationship with difficulties that can't seem to get resolved. This leads to students wanting to quit a group or kick out some member of their group. The problem with this goes beyond the dysfunctional group and affects other groups that disassociated members try to join for the rest of the projects. Try to avoid this and ask for our advice in trying to salvage your group when problems arise. But, here is the process that must be followed in the worst-case scenario:

1. Airing of grievances -- email with cc to all group members and to the instructors with description of the dispute with or complaint against a member (e.g. lack of effort, failure to attend working sessions) and proposed remedies that could resolve the matter. Group members should attempt to negotiate a solution.
2. Allow 72 hours to resolve problem.
3. If no progress is made, notification of quitting or firing is made via email to all group members involved and the instructors. If the lone students resulting from group breakup can not find another group to adopt him or her, then the students must finish the remaining projects alone (with no lessening of requirements).

Last updated August 20, 2005