As
of next year the course will be back to 6 UoC. Do you have any suggestions
on how to change it (in particular the project) so it will be a reasonable
6UoC load, without being too detrimental on what students get out of it?

That damn ipstack...
it would have been very nice to write our own network driver as we did for
the clock (although I know this is not a trivial task). A better written
ipstack would be very nice.

5.

The lack of sleep.

6.

maby the work load, but if pays it's self back in the end

7.

The project -- some
components depended on earlier milestones.. Lecture notes..I don't generally
get a lot out of lectures and I depend on lecture notes.

8.

Not enough material from the current OS projects aroud the world.

9.

Lack of a debugger for L4 =-) You can only test functions somewhere where debuggers are available so much.

10.

The exam. Unfortunately
I can empathize that it would be difficult to choose, given that you have
people like myself who are wet behind th ears, and others that have done
a whole thesis on a production OS (Mungi). It would be hard to choose, though
I still thought that it didn't fully test our understanding of the subject
matter.

11.

The exam.

12.

Lecture subject matter not well tied in with practical side of course.

13.

The lectures, project
and exam all had nothing to do with each other. Some parallelism required.
A lot of the project is not so OS relevant, and the exam was really a test
of general knowledge, and also not so OS relevant (paper 2). However, the
biggest problem is the prerequisites. Should easily be a HD in 3231 plus
clearly stated assumed knowledge. Would definitely have affected my decision
to take the subject.

14.

the lectures that were not related to the project

9.

What
background knowledge do you think you were missing that would have helped
you in this course? Is credit in COMP3231/9201 and a co-requisite of Computer
Architecture a suitable preparation?

Credit in 3231 certainly
a must... not sure about comp arch though since i didnt do it (hmm... this
survey supposed to be anonymous rite?)

4.

I'm not sure how related comp arch really is, not by much I think. I wish I knew more about L4 before starting the project.

5.

I am glad I did microprocessors
as well because that taught me about manipulating hardware with assembler.
It would be suggested that others take this, but it was not absolutely required.

6.

AOS does assume a lot of background I don't realy know
where to start... but you just need to know a lot.

7.

I don't computer
architecture helped me very much. It helped me understand multiprocessor
issues from both a hardware and OS point of view, but that's about all.
And I think a better than credit grade in COMP3231 is necessary to do reasonably
in this course. Better understanding of networks. I think I learnt more
about network programming in this course than in COMP3331, which is rather
sad.

8.

An experience in COMP2041 will be useful, also a backgroud in Computer network is related for the project.

9.

co-requisite of computer architecture didn't help much

10.

That was all the
preparation that I had. I don't even think that the computer architecture
was necessary. It might even prove a hinderance. I did this subject in my
first thesis year, and there were other 4th year subjects that I wanted to
do. Essentially the computer architecture course made me do another 6 credits,
so totalling 18 credits to do AOS. Comp Arch was intresting, but I could
have easily survived the course without it.

11.

Yes.

12.

COMP3231 was appropriate background, computer
architecture was less important.

13.

As stated, certainly
not. A person with just the required background has absolutely no chance
of coming even close to passing. Networks, and in particular strong UNIX
programming experience are required as well as good "general knowledge" of
computing which comes mostly from experience. Need clear assumed knowledge.

The actual
OS imlpementation experience from the project... the lectures are interesting
background, but not specifically relevant.

2.

Well implementation experience learnt from the project... general system design principles (microkernel?)

3.

Protection, caching, page tables, pretty much most of it.

4.

Almost everything...
I have always wanted to know how a computer works at every level and with
the help of this course, I can say I have that knowledge.

5.

multiprocessor issues, real-time issues.

6.

Mungi and More about other OSs out there.

7.

The general topics I found fairly interesting.

8.

The microkernel idea is very interesting and have the potential to be developed more in the future. Also the security concept.

9.

The stuff on protection & caching and TLBs

10.

A lot of the protection,
caching, multiprocessor, and file system issues will be very important. I
am currently looking into a thesis with multi-processor programming. The
crypto stuff would be HEAVILY useful for what I want to do as well.... unfortunately
I have done it all.

11.

Cool stuff mainly but also
caching and TLBs
Page tables
protection, part capabilities

12.

Developing over a long period of time. The more general OS topics. (Commercial issues - Not L4, not Mungi).

13.

microkernel knowledge
page table knowledge

13.

Which material, not currently in this course, would you liked to have seen covered?

Issues such as distribution and network file systems, but they are probably best suited to another course.

2.

maybe it's taboo but can u talk something more regarding Windows or popular non-unix like OS, eg a few case studies?

3.

Not sure what else is there.

4.

I think we pretty much covered everything.

5.

I'd like to see a
mixture of traditional kernel design and implementation and microkernel.
Fair enough that we use microkernels in the group, but other kernel designs
are also interesting.

6.

a bit more UNIX stuff to make a contrast with

7.

How architecture
design affects systems programming/performance -- it is covered to some extent
in the lectures, but not enough in depth.

8.

The microkernel concept
is very interesting and could probably dominate the next generation of OS,
but it is also a good thing to open our mind to the other related area of
OS (I found the exam material is also very interesting, that such topic is
good as well).

I've said it before,
and I'll say it again... I don't enjoy going thru assembler code in lectures.
Although it does give you an understanding of IPC techniques, its nothing
that a few well drawn pictures and notes can't explain :-)

5.

none

6.

The Crytography lecture was interesting, but I don't see how that relates directly to OS.

7.

All of the materials
are OS stuff followed with examples, but the examples mainly are from an
old research projects. I guess it will be more interesting to have less old
research project examples and give more examples from the current research
projects.

8.

The implementation material in the lectures.

9.

The project is too much work, and too hard. I didn't get enough out of doing it to justify the time I spent on it.

Keep the exisitng
project spec so that the new-comers will suffer what we had! muahhhhhhhhhhhhh.........
Anyway, maybe FAQ can be updated and integrated together (the one in Aysst
lab page and project faq) for next yr. If the exact same project is going
to be continued, extra one wk will be good, coz the late submission (-6 each
wk for second last milestone) is a bit too harsh and one wk is not too long,
but enough to avoid this late penalty

3.

A more robust network
driver being provided might make the network aspect easier without ruining
the integrity of the project as well as clear description of what precisely
is required for milestone 4

4.

Scheduling would have been interesting.

5.

Just as I mentioned eariler, writing our own ipstack that better than the supplied one.
Ooo Ooo.... and a source level debugger :-)

6.

I think the project
is very good. It teaches a lot about system design in a very short period
of time. It was well worth the sleepless nights :)

7.

It's been a while since I've looked at it.....
looking back at it, it was a good size.

8.

Build a distributed OS :) Perhaps after the second half of the course everyone involve in buiding a big project as a team.

9.

I understand that
the network and file IO protocols could have taken some people a lot of work.
The rest of the system was quite enjoyable. I would have loved to have done
the bonuses, but there was no time to. Particularly, the shared memory would
have been great (esp if you chose an IPT to implement the pager structure)

As
of next year the course will be back to 6 UoC. Do you have any suggestions
on how to change it (in particular the project) so it will be a reasonable
6UoC load, without being too detrimental on what students get out of it?

I don't think
6UoC is a good idea... however, I think the number of compulsory parts should
be reduced and maybe students could be required to pick a limited number
of them to imlpement. Obviously this is limited to only smoe of the milestones,
but letting people choose which parts to implement is a good idea. Whatever
you do, don't increase group sizes.

2.

Run the 6UoC as a
yearly course - just like software engineering workshop - 3 UoC each session.
Since only good students are expected to do it (seriously, who actually picked
"Looking for easy 12 UoC"???), you can expect quite some amazing, impressive
project from students if you give them lots of TIME (which we did not have,
otherwise we would have done the bonus or tidy up the existing code at least)...
and the super bonus may turns out to be reality (finally?) Of course this
brings more problems whether people still wanna do this course if the course
is planned this way.... My 2 cent

3.

The network part might make things difficult. Also, having time to implement a malloc would have made things easier.

4.

The only thing I
can think of since it is probably too much for them to build the entire OS,
is to have each group implement a few components and integrate them all together
to create an OS?!?

5.

I think it's a shame
that the course has to go back to 6 uoc. It is a hard course, but a lot is
learnt and well worth the 12 uoc.

6.

I thinks it's a bad thing.
watering it down might make it too lite
and craming it in would make it a unreasonable for 6u

7.

Giving more reference for the project such as the networking part would help to make it more reasonable for 6UoC load.

8.

Organize with what
OS did the semester beforehand. I found the pager implementation for this
really easy, but only because I already wrote it for OS. If you choose two
topics for OS (say simple Pager and perhaps a project on asynchonization
or concurrency) and another three or so for AOS, then three will be a large
coverage of OS design issues, without the workload of having to implement
a whole system. The crucial ones that students need to do are: * Pager with
ASIDs and demand paging * Process management * Clock driver (for the experience
of interrupts) * File management I think the network wasn't so needed (as
most people have already done this in networks before), nor was the documentation
(although this was probably needed that you had some sort of understanding
of what our code did)

9.

Remove bonuses from project - the time taken for
the project is an exponential function of the number
of bonus components attempted - without these it is fairly straightforward. The lecture/exam component doesn't need changing.

10.

Mentioned above..
A lot is simply not so AOS relevant, and some is even too elementary. In
all cases, the amount of work was over the top.

11.

I think that's a bad idea since I thought that I
learnt most frm doing the project, and the project
just takes that much time