Comments on our Bespoke Survey

I'm very pleased to see that all but one of the enrolled students completed the survey (bribing with a t-shirt may have helped ;-) This certainly provides valuable feedback.

General comments

The results mostly speak for themselves. The course seems to be in good shape, overall satisfaction was very high, some critical comments notwithstanding.

We are grateful for all the positive and encouraging comments, I won't discuss them, but be assured they are well received by the team! Let's look at the critical comments that address issues under our control (and changing which would not obviously be at odds with the overall objectives for the course). Also, I'm skipping comments that are already addressed in the myExperience response.

Blue font indicates concrete action items.

Q1: Quick evaluation

It's great to see the strong approval scores for all people involved (individual lecturers as well as the class of tutors), with "excellent" dominating. It's pleasing to see that their commitment is appreciated.

Q9: Worst things

All these came up in the myExperience survey and are addressed in that context. However, one seems to merit more discussion:

Odroid issues

This came up in myExperience as well. Given how many people mentioned it, it seems to have been a bigger issue than we were aware of.
We'll make a real effort to get this sorted for next year.

I suspect the average mark handed out is significantly lower than the average WAM of students who finish the course.

Historically the two are pretty close, in fact. This year they were spot-on for the 10th decile. AOS marks were lower than WAM for the 9th decile (and, of course, very few students get in with a WAM in the 8th decile). We did have a record fraction of HDs (see stats page)!

The exam hurdle is unconscionable

We actually never failed a student on the exam hurdle alone, so it seems to serve its purpose of ensuring that students take the exam seriously.

The disconnect between lectures and the project/exam.

Not sure which disconnect. The exam tests a lot of the general systems insights we aim to get across in the lectures. This is very deliberately part of the course.

Also a broader discussion on how other OSs implement things

It would definitely be possible to explore more of this, but we'd have drop something else. We'll consider extending the Linux lecture.

Q17: What should be added?

Kernel bypass networking?

I'm tempted to step into this one, we'll see how our own work in competing with a principled microkernel-based design goes there ;-)
Will still leave the issue of what to drop, though.

Writing device drivers

This came up last year as well, and it sort-of relates to the above. Unfortunately, writing real drivers isn't going to fit into the project, keen as I am to do so. But I'll seriously consider adding this (and possibly kernel-bypass schemes) to the lectures.

Windows internals

We'd love to do this, but we don't have anyone with the competence for this, unfortunately.

Bring distributed systems back

I'm totally with you!
Unfortunately, this one is totally out of my control...

Q18: What should be excluded?

No clear votes for anything specific, and the things mentioned are all topics that were popular with the majority of people. My take-away is that there's no strong argument for dropping any specific content. The ones that seem least clear-cut are:

Some of the formal verification, especially the history of OS verification

I'll see whether it makes sense to scale this back without making the later stuff harder to understand.

User-level sync primitives

... had one in favour and two against ;-)
Since it was a guest lecture it might be a one-off anyway.

Q9–21: Lecture attendance

As stated in the questionnaire, lecture attendance was actually quite good (particularly by post-pandemic standards), with about 50% attending most lectures in person.

Believe me, I really appreciate this! Talking to real people and getting people to ask and answer questions for me personally makes a big difference, and I'm sure has a strong positive effect on lecture quality.

In that sense it's pleasing to see that the predominant reason for not attending live lectures was workload / time pressure. It seems students do value the live lectures and will attend them when they can.

Q25: Difficulty of various parts

This looks reasonably balanced, although M5 sticks out as being hard. Prior to trimesters we could afford another week for that one...

Q26: How well specified?

This looks fine to me, given that we intentionally don't want to be too prescriptive.

Q27: Quality of...

Supplied code

Big improvement over last year! This is good to see, because we did improve the code a lot, but probably still not perfect. We'll see whether we can improve it further.

Hardware platform

Odroid issues were mentioned before. Results are actually better than last year (and we did some work) but clearly should be improved more.

Q31: Final Comments

Some comments about difficulty and being more up-front about it.

I think we really do what we can, including publishing all student feedback uncensored, and warning students in the first lecture to be disciplined.

Thanks again for the very nice words, they are a great encouragement for the whole team!

Final

Thanks for the feedback, and your participation in the course!

Gernot