Duke Univ - CPS110 Fall 1998:Policies

CPS 110

Introduction to Operating Systems

Fall 1998

Policies and Administration

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 projects using the notorious Nachos instructional operating system.

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. Familiarity with C, C++, and basic Unix program development tools (e.g., gmake ) is assumed.

Workload. This is a demanding course. There are seven required Nachos programming assignments, with one due every two weeks. To make things a bit easier, you will work through the Nachos projects in teams of three or four students. As in previous offerings of CPS 110, you will present your projects in demo sessions with the instructor or the TAs. These projects will be fun and valuable if you form teams quickly, start early on the projects, and make your Nachos work a priority this semester. In addition to the Nachos assignments, there will be optional problem sets, one or two in-class exams, and an in-class final exam.

Textbooks and Other Resources

Operating Systems: A Modern Perspective, by Gary Nutt

All course materials, lecture slides, and announcements will be accessible via the course web site at http://www.cs.duke.edu/education/courses/cps110/current/. You will visit this web site often, as we will rarely hand out printed materials in class. Grades are also distributed through the course web: please see Darrell for a password.

There is also a course newsgroup duke.cs.cps110 . 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.

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): I grade on a curve to compensate for any possible problems with the projects and exams.

Policies

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 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.

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) 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. This applies when the assignment is supposed to be an individual effort or whenever two teams discuss common problems they are each encountering (inter-group collaboration). 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.
  2. The Freedom of Information Rule: To assure that all collaboration is on the level, you must always write the name(s) of your collaborators 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). We want to know about dysfunctional group situations as early as possible. To encourage everyone to participate fully, we make sure that every student is given an opportunity to explain and justify their group's approach to the Nachos projects.