This course will provide an introduction to operating system design and implementation. The operating system provides a well-known, convenient, and efficient interface between user programs and the bare hardware of the computer on which they run. The operating system is responsible for allowing resources (e.g., processors, memory, and disks) to be shared, providing common services needed by many different programs (e.g., filesystems, the ability to start or stop processes, and access to hardware devices), and protecting individual programs from one another. Particular emphasis will be given to three major OS subsystems: process management and synchronization, memory management, and file systems.
Primary course goals include:
CSCI 2330 (Foundations of Computer Systems). Familiarity with C is expected, but prior experience with C++ is not required or assumed.
Instructor: Sean Barker
Office: Searles 220
Phone: 207-798-4220
Email:
My regular schedule of office hours will be posted to the #schedule
channel in the Slack.
Mondays and Wednesdays, 1:15 pm-2:40 pm.
All class meetings are held in Searles 223.
Students are expected to exercise good judgment with respect to masking and attending in-person classes. If you test positive for COVID, you should let me know and pause any in-person attendance of classes and office hours. I will work to support you during the time you are isolating.
Students exhibiting mild symptoms of illness (cough, runny nose, etc.) who test negative for COVID and feel well enough to attend class may do so, but are requested as a courtesy to others to mask until symptoms have fully resolved. If you do not feel well enough to attend class, or if you suspect you may have COVID, please let me know.
We will reference the following textbook, which is freely available online:
Remzi Arpaci-Dusseau and Andrew Arpaci-Dusseau. Operating Systems: Three Easy Pieces.
Individual chapters of the book are downloadable as PDFs from the site above. If desired, you can also purchase a hard copy of the book from the website to supplement the free electronic version.
Course requirements include completion of 4 programming projects, 4 problem sets, 2 exams (midterm and final), and attendance and participation during all class sessions. Evaluation will be as follows:
Projects after the first will be completed in groups of 2 or 3 and will be evaluated on program correctness, sound design, proper coding style, and the quality of your project writeups. You should expect to spend most of your time on this class working on the projects. While you will have roughly 2-3 weeks to complete each project, it is essential that you start the projects early and work steadily.
Each assignment has several important dates: a release date, an acceptance deadline, possibly one or more checkpoints, and a final due date. Further details are given below.
The assignment writeup is posted on the release date. Following this date, the acceptance deadline is the date by which you must form a team (if working in a group) and "accept" the assignment on GitHub, which will initialize your team's repository and allow me to add any team-specific files. Accepting the assignment only takes a minute or two, and the acceptance deadline is normally a few days after the release date.
For some assignments, checkpoints are intermediate deadlines at which time part of the assignment is due. Checkpoints are designed to help you work steadily and seek out assistance early if needed. Checkpoints are ungraded, but failure to meet a checkpoint is a warning that you are not currently on track to comfortably complete the assignment. If you will not or do not meet a checkpoint, you should contact me to indicate (1) where you are in the assignment, (2) what difficulties you are experiencing, and (3) what your plan is to catch up. Extra flexibility with deadlines will not be offered if you have missed checkpoints without contacting me.
To provide reasonable no-questions-asked flexibility with final due dates, you are allotted five flex days for the semester, each of which may be used to submit an assignment up to 24 hours late without penalty. A maximum of three flex days may be applied to a single assignment. For group projects, applying a flex day uses a flex day from each group member's allotment, but can be applied as long as at least one group member has a flex day remaining. Flex days do not need to be applied towards checkpoints, but you should let me know regardless if you will not meet a checkpoint. Beyond the use of your flex days, work will not be accepted after the due date unless I have approved alternate arrangements in advance of the deadline.
We will use Slack to facilitate communication and discussion outside of class. Slack supports both traditional 1-to-1 communication (Direct Messages / DMs) and forum-style discussions with multiple participants. You should prefer messaging me over Slack instead of sending me email, as it is will be easier to keep track of class-related communication and will result in faster responses. You will get set up on Slack as part of the first class assignment.
I will normally respond to Slack messages within one business day (and often sooner). While I may respond to messages outside of regular working hours (evenings, weekends, etc.), you should not expect as such. If I have not responded to a message within two business days, your message may have slipped my inbox, so please feel free to send me a followup reminder.
Collaboration is important and valuable in computer science and some assignments in this course will permit working in a group. This section describes expectations and requirements for completing group work in this course.
For all group work, a single copy of the assignment will be submitted. Group members are expected to fully collaborate on the work, and all group members are responsible for understanding all parts of the assignment. In other words, you should not plan to split the work between the group members and complete the parts independently; instead, the expectation should be that you will work collectively as a group. For programming assignments completed in groups, most or all programming should be done with all group members working in front of a single (physical or virtual) computer. Group members should take turns ‘driving’ (writing code) and ‘directing’ (looking at the code and offering suggestions and feedback).
Note that this model of groupwork means that you should choose your group members carefully and deliberately. In particular, you should consider both your individual working styles and schedules; you cannot be an effective team if you cannot find suitable chunks of time to collaborate synchronously. If you want to work in a group but don't have a partner in mind, let me know and I can try to match you. Working in a group on one assignment does not commit you to working in the same group (or in any group) on future assignments.
As discussed previously, groups must be formed by the assignment acceptance deadline, which is typically a few days after the assignment is released. Accepting the assignment on GitHub constitutes forming your group. Group changes following the acceptance deadline are not normally permitted for the duration of that assignment. However, in the event that your group is not working smoothly for any reason and you do not believe it will be resolved, you should let me know as soon as possible. I can't address a problem that I don’t know exists!
Group reports: Each student working in a group is required to send me an individual group report at the conclusion of each group assignment. Your group report must (1) identify your partner(s), (2) summarize your own contributions to the assignment, and (3) summarize your partners' contributions to the assignment. The purpose of these reports is to provide mutual accountability within your group and to ensure that groups are functioning well. These reports do not need to be overly detailed and are often of the form "I worked with my partner on the entirety of the project together at the same time." Note that I reserve the right to adjust individual grades up or down from the group grade in cases of clear inequity. Group reports should be DM'd to me on Slack and are due at the same time of the assignment itself. Your assignment will not be considered submitted until both the assignment and your group report is received! Your randomly generated Slack string is wareri (save this).
Please review the Computer Science Collaboration Policy. You are responsible for reading, understanding, and adhering to this policy.
Group work follows the standard guidelines described above, with the exception that collaboration between members within the group is unrestricted and does not need to be cited. Any collaborations outside of the group must follow the standard guidelines.
Any use of generative AI (e.g., systems like ChatGPT) should follow the same basic guidelines as for any other external resources, as detailed in the collaboration policy above. For example, any use of ChatGPT should be cited, and you should not blindly ask ChatGPT for solutions (in the same way that you should not Google for solutions). Even beyond any concerns regarding the Honor Code, doing so is likely to shortchange your learning and lead to poor performance on exams. However, if you have a use case for generative AI that you believe might be legitimate, please ask!
Feedback is welcome on all aspects of the course as we go, either by DM on Slack or by using the anonymous feedback form. Send feedback early, as the sooner that it is received, the more likely it is that adjustments can be made in response.