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?
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.
Also known as "the dinosaur book".
Currently available in the bookstore. This is a new edition. Previous editions have been used in the past and are still OK to use this term, so you
may be able to pick up a used book without a lot of trouble. Just do a "sanity check" comparison on the numbering of exercises assigned from the new book to catch any critical changes.
You might also want to pick up a book on C that suits your tastes.
I will make at least one copy of the new edition of the main textbook available for use
in the engineering library.
Computer Resources
You should have an account on the CSE DEC Alpha instructional machines.
If you do not, see the CSE main office for a form.
You'll need to know how to use several pieces of software in this class.
The UNIX operating system shell.
mail, grep, ls, etc.
The Web
You already know enough about the web to have gotten to this
point.
Everyone in this class should set up their own home page if they
haven't done so already. The details of getting that page linked into
the class web will be announced shortly.
Programming utilities.
You'll need to know how to use tools like the C compiler, make,
and a debugger (either dbx or gdb) in order to do the programming
assignment. You'll also need to become facile with an editor (e.g., emacs). You're on your own for using these
tools; we will not be spending any time in lecture on them.
Learning Activities and Evaluation
As instructor, my most visible teaching activity is giving lectures; however,
my more important role is probably that of defining constructive activities for you to do to help you learn (i.e., identifying material to be read, problems to be solved, and projects to be programmed). Establishing a grade in the course by evaluating the results of these learning activities is 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 (36%). Hands-on experience that will develop skills and give you an in-depth appreciation for some of the details and concrete design issues.
4 Written Homeworks (16%). These problem sets will come from the textbook readings and give you a very valuable preview into the content of the exams. The purpose of the readings and homework is to fill in the breadth that the specific projects can not address.
Exams - one midterm (20%) and final (25%).
Course participation (3%). I would like this to be an interactive class, so ask questions and offer ideas freely.
Please don't even consider turning stuff in late.
Barring exceptional (extreme) circumstances, we will not accept late turnins
and will not consider granting Incompletes as a grade.
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 I are reasonable people, and we expect that
everyone else involved in this class is as well.
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. If you cheat, you risk losing your
position as a student in the department and the college. The department's
policy on cheating is to report any cases to the college cheating committee.
What follows that is not fun.
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.
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.
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.
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.