Comments on our Bespoke Survey

I'm very pleased to see that all but one student did 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. This is particularly pleasing as we had to get back into full on-line mode after the pandemic forced another lockdown from Week 5. It is clear that students enjoyed the lab experience while it was there, and missed it once it was gone. This is a great endorsement of our preferred setup for the course.

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.

Q7: Worst things

odroid infrastructure crashing :p: I asked around and generally people found the Odroids reliable. There was a bug in the (unverified) AArch64 kernel which someone managed to trigger, so you may have been the unlucky one (and would have qualified for bonus points if you had managed to make it reproducible). We have improved the infrastructure to reboot the Odroid in the case of a kernel crash.
Ambiguous specs: As explained in the myExperience response, the project is intentionally under-specified to force you to think about the design. However, there was some misleading wording in the M5 spec which we fixed.
Poor intro to seL4, more lectures dedicated to this (and other questions referring to being told/shown more): Again, this is intentional, we want you to work things out by yourself. This is specifically important in the first few weeks, so students who are not up to the task can drop early.
However, talking to people I hear that I should spend more time on the sample code in the lecture slides, will do that.
“Could have been slightly better on discussing the things on the research front...”: See below comments re system design, industry etc.
“... and slightly more space for the assignment submission could have been given...”: see corresponding comment in the myExperience response
“...and showcasing the failed autotests for the milestone 7 so that an idea of where the system failed could have helped a bit more.”: We'll consider what we can do to provide more transparency. However, we really want to avoid students making their system just good enough to pass our test suite, that would undermine our learning goals.
Incomplete documentation, "TODOs" in PDF: Indeed, there are a whole lot of TODOs in the MCS-specific parts of the manual. Given that by now the MCS kernel is fully formalised and verified to the executable spec level, this really needs fixing. Apologies for this...
Poor communication on how things are tested: Again, that's a feature. We don't want you to implement your system so it passes auto-testing, we want you to do it right. In the real world it isn't the test suite that counts, but whether your system works under all circumstances.
Warning should be given about thread-unsafe libraries: Fair comment, we'll try to document what isn't thread safe.
The project was a bit slow to get started (rip trimesters): This comment is a bit ambiguous. My first reading was a complaint about not starting quickly/challenging enough (which is definitely not the opinion of the high-performers I talked to). On reflection I think the student meant the opposite: the learning curve is steep. But that's a feature.
It would have been nice to see some final feedback about our projects rather than just the mark.: There are no comments as such, but we'll try to provide a bit more transparency about project marking.

Q8: What could have been done better in the pandemic context?

I'm skipping this as we should hopefully be pandemic-free this year....

Q17: What should be added?

As I already mentioned, we should have also asked about a life lecture, sorry.

More on seL4 programming, or demo: Will spend more time in the lecture going through sample code.
More on system design on top of microkernels. Applications in industry.: Good suggestion, I'll see what I can do this year.
More on monolithic kernels, Windows, Linux, FreeBSD, etc: Well, we do have a fair amount of Linux. We don't have Windows/FreeBSD expertise.
Optional lectures on various stuff: You'll get all of that if you join TS, we have weekly seminars ;-)

Q27: Final Comments

An idea: have a live leaderboard with fastest FS times in all 3 categories, essentially game-ifying the FS bonus mark for the second half of the term.: Nice suggestion, we'll try that this year!