| Survey ID | 1302 |
| Title | COMP9242 11 |
| Description | Course Evaluation Survey for COMP9242 Advanced Operating Systems. Version for Session 2, 2011. |
| Anonymous | Yes |
| Fill Ratio | 95% (18/19) |
| # Filled | 18 |
| # Suspended | 0 |
| # Not Filled | 1 |
|
 indicates required field |
|
|
Your comments will help us to assess and improve our courses, not only for future generations, but for your further study in CS&E. We really look at the results and appreciate your feedback! Several changes to the course over the years were a direct result of student feedback. And, as always, we'll publish the uncensored results on the course web site.
Note: Please do not enter "no comment" or something similar into comment boxes. If you don't have anything to say, just leave the box empty.
|
|
|
|
| 1.
|
Give a high rating if you have a good opinion of something (e.g. interesting, useful, well-structured, etc.). Give a low rating if you have a bad opinion of something (e.g. too slow, confusing, disorganised, etc.)
|
|
Question type : Single answer -- Radio Button |
|
| |
Excellent |
|
Satisfactory |
|
Poor |
| Gernot Heiser |
11 (61%) |
7 (39%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Guest lecturer Ihor Kuz |
7 (39%) |
8 (44%) |
3 (17%) |
0 (0%) |
0 (0%) |
| Guest lecturer Leonid Ryzhyk |
5 (28%) |
8 (44%) |
4 (22%) |
1 (6%) |
0 (0%) |
| Guest lecturer Toby Murray |
5 (28%) |
11 (61%) |
2 (11%) |
0 (0%) |
0 (0%) |
| Guest lecturer Peter Chubb |
7 (39%) |
9 (50%) |
2 (11%) |
0 (0%) |
0 (0%) |
| Guest lecturer Etienne Le Sueur |
8 (44%) |
9 (50%) |
1 (6%) |
0 (0%) |
0 (0%) |
| Guest lecturer David Greenaway |
6 (33%) |
11 (61%) |
1 (6%) |
0 (0%) |
0 (0%) |
| Tutors/demonstrators |
9 (50%) |
8 (44%) |
1 (6%) |
0 (0%) |
0 (0%) |
| Exam |
3 (17%) |
7 (39%) |
6 (33%) |
2 (11%) |
0 (0%) |
| Course web pages |
5 (28%) |
6 (33%) |
7 (39%) |
0 (0%) |
0 (0%) |
| Reference material |
5 (28%) |
6 (33%) |
6 (33%) |
0 (0%) |
1 (6%) |
| Computing resources |
6 (33%) |
6 (33%) |
5 (28%) |
1 (6%) |
0 (0%) |
| COMP9242 overall |
9 (50%) |
8 (44%) |
1 (6%) |
0 (0%) |
0 (0%) |
|
|
|
|
| 2.
|
Which factors most influenced your decision to enrol in this course?
|
|
Question type : Multiple answer -- Check Box |
|
|
Interest in operating systems as an area of study
|
16 (89%) |
|
|
Chance to build a system
|
12 (67%) |
|
|
Chance to get fingers really dirty
|
11 (61%) |
|
|
Would like to do some systems research
|
7 (39%) |
|
|
Looking for a challenge
|
17 (94%) |
|
|
Looking for an easy course
|
0 (0%) |
|
|
Friends told me it was good
|
9 (50%) |
|
|
|
| 3.
|
Other factors not mentioned above?
|
|
Question type : Short-answer |
|
Answer at the bottom page (3 comments) |
|
| 4.
|
Would you recommend this course to another student such as yourself?
|
|
Question type : Single answer -- Radio Button |
|
|
Yes
|
18 (100%) |
|
|
No
|
0 (0%) |
|
|
|
| 5.
|
The course is heavy on design and implementation issues. It also tries to remain close to present research issues (although that aspect has suffered with the move to 12 teaching weeks). What do you think about the content allocation?
|
|
Question type : Single answer -- Radio Button |
|
| |
Too
much |
|
Just
right |
|
Too
little |
| Theory/general principles |
0 (0%) |
5 (28%) |
10 (56%) |
3 (17%) |
0 (0%) |
| OS design and implementation |
1 (6%) |
0 (0%) |
13 (72%) |
4 (22%) |
0 (0%) |
| Current research issues |
1 (6%) |
2 (11%) |
10 (56%) |
5 (28%) |
0 (0%) |
|
|
| 6.
|
What were the best things about this course?
|
|
Question type : Long-answer |
|
Answer at the bottom page (17 comments) |
|
| 7.
|
What were the worst things about this course?
|
|
Question type : Long-answer |
|
Answer at the bottom page (17 comments) |
|
| 8.
|
How does the workload in this course compare to workloads in other ...
|
|
Question type : Single answer -- Radio Button |
|
| |
Much
Lighter |
|
Similar |
|
Much
Heavier |
| COMP courses at this level |
0 (0%) |
0 (0%) |
3 (17%) |
6 (33%) |
9 (50%) |
| COMP courses in general |
0 (0%) |
1 (6%) |
0 (0%) |
3 (17%) |
14 (78%) |
| Courses in general |
0 (0%) |
0 (0%) |
1 (6%) |
3 (17%) |
14 (78%) |
|
|
| 9.
|
How does the overall quality/value of this course compare to other ...
|
|
Question type : Single answer -- Radio Button |
|
| |
Among
the best |
|
Average |
|
Among
the worst |
| COMP courses at this level |
12 (67%) |
2 (11%) |
4 (22%) |
0 (0%) |
0 (0%) |
| COMP courses in general |
13 (72%) |
4 (22%) |
1 (6%) |
0 (0%) |
0 (0%) |
| courses in general |
12 (67%) |
4 (22%) |
2 (11%) |
0 (0%) |
0 (0%) |
|
|
| 10.
|
What background knowledge do you think you were missing that would have helped you in this course? Is distinction in COMP3231/9201 a suitable preparation? Is it too harsh?
|
|
Question type : Short-answer |
|
Answer at the bottom page (14 comments) |
|
|
|
| 11.
|
Please rate the relevance/appropriateness of the lecture topics.
|
|
Question type : Single answer -- Radio Button |
|
| |
Very
relevant |
|
Average |
|
Inappropriate |
N/A |
| Microkernels and seL4 |
13 (72%) |
3 (17%) |
2 (11%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Caches |
9 (50%) |
7 (39%) |
2 (11%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Threads and Events |
11 (61%) |
7 (39%) |
0 (0%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Virtual Machines |
7 (39%) |
9 (50%) |
2 (11%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Device Drivers |
3 (17%) |
12 (67%) |
3 (17%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Performance Evaluation |
13 (72%) |
4 (22%) |
0 (0%) |
1 (6%) |
0 (0%) |
0 (0%) |
| Multiprocessing |
7 (39%) |
9 (50%) |
2 (11%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Linux Internals |
6 (33%) |
5 (28%) |
6 (33%) |
0 (0%) |
0 (0%) |
1 (6%) |
| Power management |
5 (28%) |
6 (33%) |
5 (28%) |
1 (6%) |
0 (0%) |
1 (6%) |
| Microkernel Design |
10 (56%) |
7 (39%) |
1 (6%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Hot Topics |
6 (33%) |
8 (44%) |
2 (11%) |
1 (6%) |
0 (0%) |
1 (6%) |
| Sample paper analysis |
11 (61%) |
4 (22%) |
2 (11%) |
0 (0%) |
0 (0%) |
1 (6%) |
| Local Systems Research |
4 (22%) |
12 (67%) |
2 (11%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Security |
10 (56%) |
6 (33%) |
1 (6%) |
1 (6%) |
0 (0%) |
0 (0%) |
|
|
| 12.
|
Please tell us how interesting you found the lecture topics.
|
|
Question type : Single answer -- Radio Button |
|
| |
Very
interesting |
|
Ok |
|
Boooooring! |
Skipped |
| Microkernels and seL4 |
13 (72%) |
3 (17%) |
1 (6%) |
0 (0%) |
0 (0%) |
1 (6%) |
| Caches |
8 (44%) |
7 (39%) |
2 (11%) |
0 (0%) |
1 (6%) |
0 (0%) |
| Threads and Events |
8 (44%) |
5 (28%) |
3 (17%) |
1 (6%) |
1 (6%) |
0 (0%) |
| Virtual Machines |
9 (50%) |
8 (44%) |
1 (6%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Device Drivers |
6 (33%) |
7 (39%) |
3 (17%) |
1 (6%) |
1 (6%) |
0 (0%) |
| Performance Evaluation |
7 (39%) |
7 (39%) |
3 (17%) |
1 (6%) |
0 (0%) |
0 (0%) |
| Multiprocessing |
10 (56%) |
8 (44%) |
0 (0%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Linux Internals |
7 (39%) |
5 (28%) |
3 (17%) |
1 (6%) |
0 (0%) |
2 (11%) |
| Power management |
9 (50%) |
5 (28%) |
1 (6%) |
1 (6%) |
0 (0%) |
2 (11%) |
| Microkernel Design |
10 (56%) |
7 (39%) |
1 (6%) |
0 (0%) |
0 (0%) |
0 (0%) |
| Hot Topics |
10 (56%) |
4 (22%) |
2 (11%) |
0 (0%) |
1 (6%) |
1 (6%) |
| Sample paper analysis |
5 (28%) |
7 (39%) |
3 (17%) |
1 (6%) |
2 (11%) |
0 (0%) |
| Local Systems Research |
7 (39%) |
8 (44%) |
2 (11%) |
0 (0%) |
0 (0%) |
1 (6%) |
| Security |
11 (61%) |
3 (17%) |
3 (17%) |
1 (6%) |
0 (0%) |
0 (0%) |
|
|
| 13.
|
Which material do you think will be most useful to you in the future?
|
|
Question type : Long-answer |
|
Answer at the bottom page (18 comments) |
|
| 14.
|
Which material, not currently in this course, would you liked to have seen covered?
|
|
Question type : Long-answer |
|
Answer at the bottom page (10 comments) |
|
| 15.
|
Which of the current topics would you like to see scaled back or excluded?
|
|
Question type : Long-answer |
|
Answer at the bottom page (8 comments) |
|
|
|
| 16.
|
What factors caused you to attend lectures?
|
|
Question type : Multiple answer -- Check Box |
|
|
I had enough spare time
|
8 (44%) |
|
|
The lectures were too good to miss
|
11 (61%) |
|
|
Given the pace and lack of a textbook, I could not afford to miss the lectures
|
8 (44%) |
|
|
It was as good a place as any to take a nap
|
3 (17%) |
|
|
I wanted to be seen to be there
|
3 (17%) |
|
|
None, I skipped most
|
0 (0%) |
|
|
|
| 17.
|
What were the reasons for skipping lectures?
|
|
Question type : Multiple answer -- Check Box |
|
|
Overall workload in this and other courses
|
6 (33%) |
|
|
Lecture notes and references cover the material adequately
|
1 (6%) |
|
|
Lectures are boring
|
2 (11%) |
|
|
There was not enough material to justify attending lectures
|
1 (6%) |
|
|
First half of the course was more interesting than second half
|
0 (0%) |
|
|
None, I attended (almost) all
|
13 (72%) |
|
|
|
| 18.
|
Any suggestions for improving lectures?
|
|
Question type : Long-answer |
|
Answer at the bottom page (10 comments) |
|
|
|
| 19.
|
What was the level of difficulty various parts of the project?
|
|
Question type : Single answer -- Radio Button |
|
| |
Too easy |
|
Just right |
|
Too hard |
| Milestone 0 |
0 (0%) |
4 (22%) |
10 (56%) |
4 (22%) |
0 (0%) |
| Milestone 1 |
0 (0%) |
4 (22%) |
11 (61%) |
3 (17%) |
0 (0%) |
| Milestone 2 |
0 (0%) |
6 (33%) |
10 (56%) |
2 (11%) |
0 (0%) |
| Milestone 3 |
1 (6%) |
2 (11%) |
12 (67%) |
3 (17%) |
0 (0%) |
| Milestone 4 |
0 (0%) |
2 (11%) |
10 (56%) |
6 (33%) |
0 (0%) |
| Milestone 5 |
0 (0%) |
0 (0%) |
11 (61%) |
6 (33%) |
1 (6%) |
| Milestone 6 |
0 (0%) |
0 (0%) |
7 (39%) |
8 (44%) |
3 (17%) |
| Milestone 7 |
0 (0%) |
1 (6%) |
9 (50%) |
7 (39%) |
1 (6%) |
| Milestone 8 |
0 (0%) |
3 (17%) |
8 (44%) |
5 (28%) |
2 (11%) |
| System documentation |
0 (0%) |
2 (11%) |
11 (61%) |
5 (28%) |
0 (0%) |
| Project overall |
0 (0%) |
0 (0%) |
5 (28%) |
11 (61%) |
2 (11%) |
|
|
| 20.
|
How well was the project specified?
|
|
Question type : Single answer -- Radio Button |
|
| |
Very clear |
|
Ok |
|
Confusing |
| Milestone 0 |
3 (17%) |
3 (17%) |
11 (61%) |
1 (6%) |
0 (0%) |
| Milestone 1 |
3 (17%) |
4 (22%) |
8 (44%) |
2 (11%) |
1 (6%) |
| Milestone 2 |
4 (22%) |
4 (22%) |
10 (56%) |
0 (0%) |
0 (0%) |
| Milestone 3 |
5 (28%) |
4 (22%) |
8 (44%) |
1 (6%) |
0 (0%) |
| Milestone 4 |
4 (22%) |
3 (17%) |
7 (39%) |
4 (22%) |
0 (0%) |
| Milestone 5 |
3 (17%) |
6 (33%) |
9 (50%) |
0 (0%) |
0 (0%) |
| Milestone 6 |
1 (6%) |
5 (28%) |
11 (61%) |
1 (6%) |
0 (0%) |
| Milestone 7 |
4 (22%) |
3 (17%) |
10 (56%) |
1 (6%) |
0 (0%) |
| Milestone 8 |
2 (11%) |
4 (22%) |
9 (50%) |
3 (17%) |
0 (0%) |
| System documentation |
1 (6%) |
3 (17%) |
9 (50%) |
4 (22%) |
1 (6%) |
| Project overall |
0 (0%) |
8 (44%) |
9 (50%) |
1 (6%) |
0 (0%) |
|
|
| 21.
|
What was the quality of...
|
|
Question type : Single answer -- Radio Button |
|
| |
Excellent |
|
Ok |
|
Poor |
| Documentation/reference material |
2 (11%) |
5 (28%) |
9 (50%) |
2 (11%) |
0 (0%) |
| Supplied code |
2 (11%) |
5 (28%) |
8 (44%) |
3 (17%) |
0 (0%) |
| Hardware platform |
4 (22%) |
6 (33%) |
7 (39%) |
1 (6%) |
0 (0%) |
| Consultation time help/support |
11 (61%) |
4 (22%) |
2 (11%) |
1 (6%) |
0 (0%) |
| On-line help/support |
5 (28%) |
7 (39%) |
6 (33%) |
0 (0%) |
0 (0%) |
|
|
| 22.
|
This was the first year we used seL4 as the base for the project. Given the difficulty of bootstrapping seL4's resource management (especially when you don't yet know what you're doing ;-) we provided the object manager. This inevitably gets you further away from the hardware. We aren't yet sure whether we got the trade-offs right here and are interested in your comments. But we are also interested in any other suggestions for improving the project.
|
|
Question type : Long-answer |
|
Answer at the bottom page (13 comments) |
|
|
|
| 23.
|
Any other comments/suggestions that might help us to improve the course in the future?
|
|
Question type : Long-answer |
|
Answer at the bottom page (10 comments) |
|
|
|
|
|
|
|
| 3.
|
Other factors not mentioned above?
|
|
1: |
John Garland told us to |
|
2: |
John Garland: "Why wouldn't you take it?! Sure, you won't sleep, but that's a positive! We waste too much time sleeping, man!" |
|
3: |
better than some other courses this semester |
|
| 6.
|
What were the best things about this course?
|
|
1: |
1. Finding the limits that you and your partner were willing to push.
2. Almost won the Maccas promotion because of AOS.
3. Course content was pretty interesting.
4. The name "SLUG" for the device. |
|
2: |
Assignments were an excellent way of putting into practice our OS knowledge. Lectures were very informative and I liked the fact that they didn't relate to the assignments so much. |
|
3: |
Challenging Course Load |
|
4: |
How the course pushed me to work incredibly hard. Even though my results at the end didn't show it, I definitely worked harder on this course than I have ever worked for a 6 unit subject (and I have taken some fairly difficult physics subjects).
The amazing tutor support. Having tutors available every working day was incredibly useful (I just need to talk the physics school into doing something similar).
Varied lectures were also good. |
|
5: |
Interesting range of lectures demonstrating the scope of OS research and ideas, |
|
6: |
Learning through practical applications. There is only so much I remember now from the lectures, but I can talk about all the little nuances of demand paging thanks to having implemented it. |
|
7: |
Major project
Quality of lectures |
|
8: |
Project. Even though it messed up my sleep, it was worth working on it. Learnt a lot. |
|
9: |
The ability to program an OS (obviously).
But also the exposure to research and real problems that the industry is currently looking at. I really enjoyed the guest lectures and liked seeing the different areas of research. |
|
10: |
The challenging OS project and the attractive NICTA office access after lecture, AND BEERS. |
|
11: |
The project is just awesome, quite an experience in life |
|
12: |
The project. It's something unique to this course, and while it's painful at times, it's usually fun and one does not go unrewarded. |
|
13: |
Valuable experience in designing and implementing modern OS features/concepts. |
|
14: |
lecture material was interesting and useful ,project-based assessment |
|
15: |
project |
|
16: |
the project |
|
17: |
the project itself. Very challenging |
|
| 7.
|
What were the worst things about this course?
|
|
1: |
1. Three hour lectures. I know it's not something can be controlled, but I know it's not just me when there's so much content jampacked into every hour that by the time you hit the next you have no idea if you retained anything.
2. Continuations/Callbacks. Urrrrrrgggggghhhhhhhhh.
3. I know you want something more meaningful, but really I'm not the guy to tell you. Some of the course content just went way over my head at times, the final exam seemed daunting because of this. The world of OS is huge...
Also, lol at the following question. I don't think you need to put that there :P I imagine the response is quite... expected. |
|
2: |
Debugging on the project is like no other debugging experience. We basically needed to be programming with care at all times, because one did not want to ever need to start debugging, it can be very painful. Coding anytime after midnight is not recommended. |
|
3: |
Disproportionate focus on microkernels |
|
4: |
Doing it at the same time as three other university courses! :P
Doing it alone for the first half of the course was terrible. However, I got an extremely competent partner in the second half and was able to implement lots of the milestones with his help while he worked on super crazy bonus marks.
3 hours straight of lecture is a pain. |
|
5: |
I don't like the chair in NICTA, and i hate the exam |
|
6: |
I personally really struggle with lectures that are more than 2 hours long. I know that this is probably more convenient for the lecturers (the have work to do as well), but I think it would be good to consider breaking it up over two days; there is more chance of the attendees of the lectures taking the presented information in.
Losing my weekends to the damn thing!!! |
|
7: |
I think there should have been a bit more detailed lectures about seL4. Out of 12 lectures, only the first lecture was on seL4, and then it was up to students to read documentation and understand its working (with the help of tutors). I think two lectures would have been better and would have avoided a lot of extra effort on students part as not everyone can invest full nights working on the project. |
|
8: |
Lack of sleep induced |
|
9: |
Lecture timing (I realise this is hard to change). Slightly disorganized when it came to the project and milestones. Milestones could've used a bit more information, especially when it came to what needed to be tested/shown/demonstrated. It seemed that we found out on the day, which meant a lot of on the spot customisation to get it to a point to be demonstrated. |
|
10: |
Project is bogged down in things we already did in normal OS course. Continuations suck. |
|
11: |
The exam. Papers are interesting but the exam itself is just way too tiring. Would prefer a much shorter exam. |
|
12: |
To little support and too heavy workload. Ending up not enough sleep is normal all over the semester, leaving other courses unattended. |
|
13: |
Typos and bugs in documentation and the code base. Given that assignments were due on Mondays, it would have been useful to have tutors more available over the weekend although I know this is a bit unreasonable to expect of them. |
|
14: |
Very time-consuming, though that wasn't unexpected. |
|
15: |
exam length |
|
16: |
lecture room was too dark, makes me sleepy. Final exam two papers in 24 hours was just torture... |
|
17: |
limited opportunity to apply lecture material in project, lecture material not assessed, groupwork, workload, ordering of milestones |
|
| 10.
|
What background knowledge do you think you were missing that would have helped you in this course? Is distinction in COMP3231/9201 a suitable preparation? Is it too harsh?
|
|
1: |
Debugging in C |
|
2: |
Doing OS would certainly have helped! Distinction is probably a fair criteria for OS. |
|
3: |
Honestly I don't think DN/HD mattered that much but it kinda reflects how much work one should expect to put into the course (doing the advanced components of COMP3231 -> AOS, but every week). |
|
4: |
I got a HD in Extended OS and I still struggled with Advanced OS. |
|
5: |
I suppose that distinction in OS is suitable, but I think a much better indicator is the "discontinue course if can |
|
6: |
I think its a good threshold, but it should not be a hard threshold. There should be exceptions to it. |
|
7: |
It |
|
8: |
Knowledge from comp3231 is sufficient for the project but not the exam. Probably needed to start reading papers before enrolling in this course. |
|
9: |
More experience IMPLEMENTING threads/continuations |
|
10: |
Possibly too harsh, but seems reasonable. |
|
11: |
Professional C skills and DN in COMP3231. It is just right. |
|
12: |
Quite suitable |
|
13: |
not too harsh. DN in OS is necessary |
|
14: |
time management |
|
| 13.
|
Which material do you think will be most useful to you in the future?
|
|
1: |
Caches, Microkernel design. |
|
2: |
Caches, device drivers. But mainly the valuable experience from the main project. |
|
3: |
Device drivers, caches, performance evaluation and power management. While not necessarily more important than other topics, they are somewhat more practical and quite a lot of emphasis is being put on them in industry development today. |
|
4: |
I suspect the experience in coding a real system is the most useful thing I take away from the course, but I think the material as a whole is a solid basis on OS and I've gained insight into how things work under the hood, which should be useful where ever I code. |
|
5: |
I would prefer working on embedded OS/embedded system itself in the future so I reckon most of the materials are useful. However the most useful part to me would be the skills gained by completing the project. |
|
6: |
Kernel design, performance evaluation and power management |
|
7: |
Knowledge about caches, threads and events, and hypervisors/VMs. Linux internals might also be useful. |
|
8: |
Microkernels
Multiprocessing |
|
9: |
Performance evaluation, caches |
|
10: |
Performance evaluation, understanding all the internals and bottlenecks in an OS |
|
11: |
Security, Microkernel design, Performance Evaluation, Device Drivers |
|
12: |
That remains to be seen :P. |
|
13: |
The concept of the microkernel, performance evaluation and virtual machines |
|
14: |
Virtualization and multi processing |
|
15: |
Will I use it? Probably not, but I'm not going into OS/OS related fields. But most of it seemed very applicable, and learning about microkernals was cool (never heard of/used one before this course). |
|
16: |
caches, multiprocessing |
|
17: |
the seL4 manual and om library |
|
18: |
working on an OS
dealing with concurrency
performance evaluation
power management
security |
|
| 14.
|
Which material, not currently in this course, would you liked to have seen covered?
|
|
1: |
A bit of more seL4 design details such as CSpaces for help in project. |
|
2: |
A look at commercial OSes. Specifically, why the idea of microkernels hasn't taken off commercially and we're all still using monolithic systems. |
|
3: |
Internals of other commodity desktop OSes? (Windows/Mac OS X) |
|
4: |
N/A |
|
5: |
N/A |
|
6: |
Perhaps more analysis of different types of OSes (same as with Linux), for interest.
More lectures to do with subjects related to the project. |
|
7: |
Possibly a bit more of a look at real scheduling (instead of the basic theory presented in cs3231). Also, more detail in the security lecture, a lot of the detail in that had been looked at previously (I.e. capability systems and Verification/Certification), and could be more interesting with more practical examples of enforcing security and how security fails in an OS. |
|
8: |
more material on real-world challenges/solutions (e.g. last year's IOAudio lecture) |
|
9: |
n/a |
|
10: |
none |
|
| 15.
|
Which of the current topics would you like to see scaled back or excluded?
|
|
1: |
Caches |
|
2: |
Device drivers are looked at in two separate instances, and while shouldn't be necessarily scaled back, the two lectures should probably be merged such that they flow better. If extra time is needed in the course, rather than cut back on material (which I enjoyed all of), rather just schedule an extra week of lectures, to make it 13 weeks of lectures. |
|
3: |
Maybe power management. Given that the OS designer doesn't have so much control over this, it seems out of place to go into so much detail about it. |
|
4: |
N/A |
|
5: |
N/A |
|
6: |
Perhaps less about current research, and more about the theory of established concepts.
However, this may be simply a difference in opinion due to my own lack of background knowledge (and as such not knowing enough to understand current research). |
|
7: |
n/a |
|
8: |
power management |
|
| 18.
|
Any suggestions for improving lectures?
|
|
1: |
3 hours is just irritating, it is better if it can be divided into 2 and 1 hour(s) |
|
2: |
Already ranted above. Though I'll say this:
It took me awhile to realise that Lectures really are just 'learning' in AOS. The final exam didn't test the knowledge we'd learned in lectures (well, not to the same extent, as in there was no ROTE learning) which is pretty fantastic, but you could comfortably HD AOS and not attend a single lecture. They don't help you with the project, and they might/might not be relevant to the final exam. It's a really interesting dynamic that happens no where else in Uni I've found so far. This isn't a bad thing... just interesting. Infact, I'm all for it.
But just please find some way to split up the lectures. THREE HOURS MAN. It's scientifically proven by science (I have zero sources/references) that three hour lectures are terrible. For those that come after me, please consider the 2hour/1hour lecture approach taken by kind course organizers everywhere. |
|
3: |
Aside from 2-3 lectures, I found the lecture material to be generally useless in terms of application to the project, but extremely interesting in terms of learning about OSes. By all means, it was all very interesting! But most of it didn't help much with the project. |
|
4: |
Break it up into two 1.5 hour lectures a week. 3 hours on a Friday afternoon is asking a lot of students. |
|
5: |
Could use a mic. |
|
6: |
DON'T MAKE THEM 3 HOURS LONG |
|
7: |
Get the projector fixed :)
Ensure that the slides are up before each lecture (I like to make notes on a printed copy of them while I listen to the lecture).
Also, it might be worth assigning a paper to read on a weekly basis and having a brief discussion of them at the start or end of each lecture. This would better prepare students for the final exam, and can be tailored for each lecture. With all the papers that come out, it's hard for students to know which to look at, so by giving a set reading, it provides a bit of direction also. |
|
8: |
Need more comfortable chairs for 3 hours lecture |
|
9: |
Two slots rather than one big one. |
|
10: |
i don't mind the friday slot but 3 hours is too long |
|
| 22.
|
This was the first year we used seL4 as the base for the project. Given the difficulty of bootstrapping seL4's resource management (especially when you don't yet know what you're doing ;-) we provided the object manager. This inevitably gets you further away from the hardware. We aren't yet sure whether we got the trade-offs right here and are interested in your comments. But we are also interested in any other suggestions for improving the project.
|
|
1: |
Alright, this is what I was waiting for.
As far as I could tell the main driving point behind seL4 was capabilities and how awesome they were.
The only interaction we had with a capability was om_save_reply_cap(...);
Were we supposed to use minting/copying/capabilities at some point? Did I miss something? It feels like om did all that magic for us, which is kinda a shame.
It was also depressing when we were doing milestone X and could see it was already done in om somewhere. We straight up copied om in terms of how it did its syscall interface (I guess that was expected though.)
|
|
2: |
Besides the timer driver and flushing TLB I hardly remember we considered other issues caused by hardware. So I guess the hardware component is probably not enough compared to the amount of software required to implement. |
|
3: |
Coming from a background with little core OS experience (except cs3231), and no prior knowledge of seL4, I still would've liked to have been a bit closer to the hardware and also the actual kernel itself. It may be worthwhile thinking about not what is necessarily different with seL4, but what is specifically hard about it (I.e. conceptually it sounds like simple resource management with an extra layer for security (capabilities), therefore the question is what is hard about the interfaces provided), and provide a set of wrappers that make it easy to deal with these aspects of the kernel, without abstracting it away too much.
These wrappers shouldn't really manage anything, just provide easier to understand interfaces, i.e. single functions that remove the need for static constants, expand the API but make it simpler in doing so. This is mainly relevant with the capabilities interfaces, which have function calls with lots of arguments. This removes the need for two sets of documentation and interfaces which becomes slightly confusing.
|
|
4: |
Given that there were many hardware features to play with, bonus parts encouraging experimentation with IO such as a sound driver/led control would have been appreciated. |
|
5: |
I actually thought the first lecture was a fantastic summary of seL4 capabilities, syscalls, kernel objects etc. So it did disappoint me to find that we'd mostly be interfacing with the object manager; rest assured the course is still highly challenging. |
|
6: |
I think it was a good trade-off. Instead of being lost in implementing object manager, the current project did a good job in ensuring that students learn how an operating is implemented and what design issues need to be considered. |
|
7: |
I thought the object manager worked well, but the one thing conspicuously absent from the project was writing a scheduler. Maybe writing a user space scheduler is difficult with the seL4 project structure, but it would be an interesting part of the project. |
|
8: |
I would have preferred to implement less of the project and have more direct control. OM abstracted too much away. |
|
9: |
It will be nice to have the object manager here because the student could focus more on algorithms and data structure rather than concerning the hardware constrains. However, for real system development, it is not a very good idea.Also the om internally has some unknown bugs as well which increase the difficulty of debugging the SOS and fault isolation. |
|
10: |
OM-server was extremely helpful. While working with seL4 directly would be really interesting (i.e. a milestone for implementing our own basic seL4 libraries would be cool), it would also be extremely difficult. Especially later on in the course when really difficult bugs are showing up, we don't want to be worrying about whether our seL4 interface works as we intended it to! |
|
11: |
The omserver was a good idea, although it had some bugs, which should be ironed out now. However, it was a strange black box in the OS and we were curious as to its allocation schemes etc. Perhaps messing with it could be a bonus mark exercise. |
|
12: |
i felt that the use of sel4/om forced us to do things in certain ways and didn't really allow for much design expression. given this and also that details of many things that an os would normally manage (caches, etc) were hidden, the project didn't really feel like it was about operating systems but more about asynchronous programming on top of sel4. there was little opportunity to exercise the lecture material.
i would have preferred if we could have had the milestones marked in a different order than was prescribed. the demonstrators themselves said that the order was largely arbitrary so i don't think it really made sense to enforce that each one be completed by a certain week. it would have been more appropriate if instead the rule was that we had to have at least one milestone checked per week |
|
13: |
the project is just right, maybe what can be done is divided the lecture of introduction of seL4 to two lecture, |
|
| 23.
|
Any other comments/suggestions that might help us to improve the course in the future?
|
|
1: |
A couple of the milestones were very similar to OS assignments, and so were a bit tedious (still useful practice though). |
|
2: |
Awesome course, it drained most of my time
Exam format maybe can be changed, spending a full day to read two papers is hard especially when we are not used to it. |
|
3: |
I found the exam to be quite intense. It took me about 3 - 4 hours to read each paper, and ended up just staying up the night to right my reports. By that point I wasn't entirely sure what I was writing made sense. Other than that, I liked the format and even the fact that it was two papers (which gave me a good perspective when writing the reports), thus my previous suggestion to get us to read papers during the semester to better prepare for it.
Also, Finally:
I think the plan to do the project on the raspberry pi is a good one.
Keep up the weekly drinks. I'm sorry I didn't have time to come to more, but enjoyed the ones I did manage to attend.
Thanks for the semester! |
|
4: |
I have rated the project hard because of the time required to do it and not the level of difficulty. Its doable (as most of the groups did it :-) ) but required a lot of time. Also, the initial start of the project was a bit hard for me as students are confronted with such a big project in the very first week. I think there should have been a bit more help in the first two weeks so that students can get on with the project a little more easily.
Please disregard my answers to 8(a), 8(c), 9(a) and 9(c) as I have not taken many courses in CSE/UNSW. There should be a field for "dont know" in these questions. |
|
5: |
I think the filesystem milestone could become something far more interesting. It was the least thought-provoking, and was really just there to test our benchmarking crimes. If the filesystem code was provided (which, it pretty much was really, we just made a wrapper around the nfs_ library) and we had to do caching/dynamic file system straight up that would've been cool/er.
Great course though, thanks for all the effort. It was fun, although sleep depriving, but I'm glad it's over. Why isn't it 12UoC again? Jesus. |
|
6: |
It would be really good to somehow give students a taste of continuations/threads/stack-switching BEFORE they have to implement it. It's very difficult to know what you'd prefer without properly experimenting with it first. Maybe have a milestone where students implement each? |
|
7: |
Make it very clear how much work the Demand Paging milestone is actually going to be. Also it should be scheduled to have the first week in the mid-sem break, rather than the second (so you get time in the holidays to do it, but also time to ask questions afterwards).
Some more clarifications on assessment would also be nice, i.e. exactly what SOS is meant to do, so we wouldn't have to guess what the tutors wanted. Automarking would be good (i.e. if we were provided with applications which we had to ensure worked correctly, more so than just SOSH). |
|
8: |
N/A |
|
9: |
While doing the project it was almost impossible to tell how you were going as compared to other groups. Conversation on the forum was sporadic and it was difficult to know if your implementation of this week's milestone was going to hold up for next week. It would have been cool to have the group who submitted the best implementation on Monday, demo their solution in the first 15 minutes of Friday's lecture. Could also make things a bit more competitive :) |
|
10: |
groups of 1 or 3 instead of 2, mor evaried assisment aapart from the projectssess |
|
|