[an error occurred while processing this directive]
School of Computer Science & Engineering
University of New South Wales
Advanced Operating Systems
COMP9242 2012/S2
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
[an error occurred while processing this directive]