/Teaching/Operating Systems/Rules and Organization

Team Registration

  • You will do your practicals in teams of four students (three or two is possible as well, but the workload per team is 700-840h — which is 7 ECTS in a team of four with 25-30h per ECTS). All of them have to be registered for the class in TUGOnline. Once you are registered, please wait up to 72 hours until you receive an invitation mail to the test system.
  • Next step: Look at the Groups in TUGOnline – there are several with different time slots for the tutorials. Choose one which suits all of the team members.
  • Log in to the test system and either start a new team there or join a team by using an join link provided to you by one of your team members.
  • Use Discord to find a team if necessary. In case you face problems finding a team, contact os@iaik.tugraz.at

We consider work or sports colleagues, friends, and relatives as conflicts of interest. Please inform us as early as possible if a conflict of interest occurs in a letter describing the nature of the conflict so that we can ensure that you are not interviewed by that specific work or sports colleague, friend, and relative. It is not possible to declare a conflict of interest during or after the exercise interview, only before.

Team Work (or not)

This course is work for 4 people. You depend on 4 people contributing an equal share. If that’s not the case, we provide you with options to get there:

  • We strongly recommend you to set internal deadlines for your team members. If you have no idea how to split the work and choose good internal deadlines, just ask your tutor for recommendations! The ideal time frame for this is a bit before the PoC deadline because for the PoC you will already implement parts. If a team member implement almost nothing for the PoC, ask the tutor how to proceed. It might be best for everyone to split up and merge with another team instead.
  • If a team member is missing internal deadlines that’s a bad sign for your collaboration. Repeatedly missing deadlines may evolve into a problem and stress for your team. Ask your tutor early what to do about this and ask whether the team member can be removed and replaced by someone from another team who faced a similar situation. Again, it will be better for everyone if no one is “carried through”.
  • If team members clearly do not contribute enough, again contact the tutor. We have some team every semester that struggle with team work; some people can very well work together others not that well, there’s immediate no big issue with that and we will try to re-merge your teams so that everyone can be productive.
  • In the worst case, it is possible to leave a team and join another team. But as all cases, you need to talk to a tutor (and potentially also with Daniel Gruss) to figure out the details of how this will work out in your specific situation.
  • If the tutor cannot resolve the problem to the extent that you’re happy with it, write to Daniel Gruss. He’ll figure out a solution that will work for everyone.
  • Disclaimer for all cases: it can be tricky to figure out who gets to keep the code written so far, so prepare for the case that you cannot and have to work in a different or new code base.

Organization of the OS course


The course provides an introduction into operating systems and their relation to the architecture of computers. In the practicals you will implement mechanisms and techniques in a operating system framework (SWEB). We will discuss History, Hardware – which services provides a processor to the OS, Processes and Threads, Deadlocks, Memory Management, Input/Output, File Systems, Multiple Processor Systems, and Security.



You won’t learn OS development by reading a book. There are different operating systems books, all of which are loved by some and dreaded by others. These include:

  • Dusseau and Dusseau – Operating Systems: Three Easy Pieces
  • Anderson and Dahlin – Operating Systems
  • Tanenbaum – Modern Operating Systems

None of these books will prepare you for what you need in the practicals. An educational resource that has been found much more useful by many students was the OSdev Wiki.


Your results in the practicals and the written exams are unified into one mark. There are different weights applied:

    • a mid-term exam: 35%
    • the practicals: 65%

To pass the class, you have to acquire

    • overall at least 55%
    • at least 50% of the possible points in the written exam
    • at least 50% of the possible points in the practicals

In case you fail to pass the written-exam-requirement, there will be a post-term-exam where you have one chance to recover. The marks are divided in

    • genügend: 55-66
    • befriedigend: 67-78
    • gut: 79-89
    • sehr gut: 90+

Formula: (% practicals) * 0.65 + (% exam) * 0.35



After discussions this semester, we added a few clarifications in italic font, to improve the transparency of the rules and make sure you have the information you need. These are no changes to the rules but an explicit statement of rules that were mentioned already, e.g., in the slides, in the lecture, or other means of communication with the students, provided here for transparency reasons.

Exercise Interviews

For each assignment there are exercise interviews with your group. The teaching assistant determines the number of points your group gets, by checking which tasks you solved and tested. You should be able demonstrate that your implementation works by running your own testcases. Usually the exercise interview is after the assignment deadline but as these are individual appointments fitted to your and our schedule we don’t exclude the possibility that the exercise interview or parts of it are before the assignment deadline.

Every participant has to implement a small task during the exercise interview. These difficulty of these tasks is comparable to the assignment tasks. Every participant also has to explain something related to their implementation – usually a code snippet, maybe while implementing the small task, etc.

If you are slow or unable to implement or explain something related to your implementation, you will get an individual point deduction. However, if you contributed a fair share to your submission, this should not be any problem.

Note that in the exercise interviews as well as in all other grading-related appointments tutors and lecturers may participate and ask questions to determine whether you achieved the learning goals, influencing the grading of this part of the course.


Exceptional Cases

Naturally, one might have a bad day. And for this purpose we have one additional regulation (starting Winter 2017/18): If the teaching assistant during the second exercise interview, gets the impression that the point deduction in the first exercise interview was not appropriate (maybe the student had a bad day, was too nervous, had a blackout, etc.), the teaching assistant is allowed to propose the lecturer team to reduce the deduction for the student by up to 50%. Note that this requires an exceptional demonstration of knowledge and skill during the second assignment interview. And, exceptional means that the teaching assistant proposes the reduction, not you 😉

Example: Student X contributed a fair share to the first assignment, but for unknown reasons had problems explaining and implementing during the first exercise interview. Consequently, Student X gets a point deduction of 30% on the first assignment. Student X contributes again a fair share to the second assignment. Now during the second exercise interview, Student X is able to explain and implement tasks, which demonstrate not only a solid knowledge of the second assignment but also the first assignment. The teaching assistant of Student X is convinced that the deduction in the first exercise interview was not appropriate. The teaching assistant asks the lecturer team to reduce it by 40%. The lecturer team in this case agrees and reduces the deduction from 30% to 18%. Student X may get a better grade because of this.


Second Chance

If you fail assignments (or the exam), you may be offered the option to take a second chance. Second chance means that you still can pass the course but you will get a deduction of 30% for every point above 55. If you participate in second chance multiple times (for different assignments or exams), the deduction will be applied multiple times. To make it more convenient for you, the TACOS test system shows the adapted grading scale for you if you participated in any second chance.

All second chances directly involve the lecturers, in terms of short talks (to determine whether you have achieved the learning goals) as part of the exercise interview or a separate appointment, influencing the grading of this part of the course.

Personal Maximum Number of Points

Although you participate in this exercise as a group, each group member gets points individually based on several factors. We have the following set of rules to determine your personal maximum number of points:

  • For each commit you unlock 0.5 points
  • For each 10 lines of code added you unlock 0.5 points
  • Max. 10 points per day can be unlocked
  • Points can only be unlocked for one assignment during the time frame of the corresponding assignment (you start at 0 on the first day of Assignment 1 and you start at 0 on the first day of Assignment 2)

You should not worry at all about this rule, the average 2015 was 58 of 50 points unlocked (averaged over both assignments). However, to make this as convenient as possible for you, you see a progress bar in the TACOS test system* showing your current personal maximum number of points. Kindly note that switching branches, removing branches, squashing commits, etc. can implicitly lead to a decrease of the maximum number of points – only thing relevant is that your personal maximum number of points is high enough on the final submission commit.


Note that only commits in the tagged (or most recent) branch are counted. Switching branches can lead to varying amounts of unlocked points.

Make sure you use the correct @student.tugraz.at address for your git commits or they will not be counted.

In the review meeting, the personal maximum number of points is applied after determining the team score, but before any individual deductions.

*We use git log --shortstat --author <email> for this purpose