Screen Version

Informal Student Feedback 1998

• Good experience!
• difficult, time consuming, but good fun
• Intriguing!
• The project made the subject pretty challenging, also its load pretty heavy. The persons who had other committments should be strongly discouraged from the subject in the future.
• Should put MIPS boxes on the desk. Easier to hit reboot button.
• Too much time hacking C code. Th ecode writing doesn't aid in understanding any OS issues that are not already covered in the 3rd year OS course (e.g. 2-level page tables, virtual address space, PCBs, file system implementation).
• I think actually implementing the 3rd year stuff does lead to a deeper understanding than just reading about it.
  A debugger that had more functionality would be great.
  I agree, we're working on it.
• Definitively an interesting subject and successful in increasing the understanding of how things work. I don't quite see the point of writing a disk driver, apart form realising that you don't have a clue what went wrong when something stuff up.
  I agree that the disk interface was a bit obscure, but, believe me, real devices are worse. However, these problems should have been fixed with the provision of the ``debugging'' disk.
• A take-home emulator would have been helpful.
  I agree, we're working on it.
• I think this subject should have more credit points, because the work required is significantly a lot more than other subjects. Or that the project should be divided into different parts where different groups can work on the parts.
  See below for a comment on this.
• The history in the U4600 window should be longer as well.
  add ``xterm*savedlines: 1000'' to your .Xdefaults.
  The second line was another student's fix. Yes, it helps reading manuals. Anyway, I've now made 2000 saved lines default for the U4600 window. (This could have easily been done earier if anyone asked for it.)
• Fun and challenging subject. The group idea should be re-thought. It does not follow that a group of 2 can do twice as much as a group of one. Milestones are good, but they are in the wrong order. There could be more test applications to test our OSes as well. On second thought, actually, the sample code was so ugly that this might do more harm than good.
  This subject was easily ten times more work than any other computing subject I have done.
  See below for a comment on this.
• Challenging subject, and I sure as hell hope rewarding too! Found milestones useful in promoting sustained effort, work was interesting, learned a lot, ultimately feel a lot better feeling the collective pain at this point. I may not necessarily burn the manuals after this.
  :-)
• More research papers should have been ountlined and made accessible from the web.
  how about going to the library yourself? I've referenced about 50 papers with full bibliography in the lecture notes!
  However, I take the point of looking at more papers in detail. A reorganisation of the subject due in 2000 will see most (if not all) of the distribution material move to a new subject, leaving more scope to look at core OS issues in depth.
• Insufficient debugging environment for project.
  I agree, we're working on it.
• Project milestone due dates are not related to difficulty (in practice)
  See below for a comment on this.
• guest lecturers not adequately informed of what we knew (what we have covered)
  Point taken.
• project boring compared to meterial in lecture
  Interesting, I'm sure the vast majority of students would say the opposite..
• lecture material VERY stimulating
• material challenging (i.e. makes you think)
• Way too much (time wise) work for the amount of credit points. The project should be something other than a bad implementation of DOS (maybe put some interesting security in it). Group aspect of project should have work segregated more to make effective use of groups, since doing roup work didn't really help.
  See below for a comment on this.

General comments

Difficulty/workload

Yes, the subject is a lot of work, but it is ment to be a challenge. This is the sort of stuff you'd be doing at MIT.
However, I accept that this year's project was a bit on the big side, and will take steps to reduce it next time around.
Comment added July 1999: The credit point value of the subject has now doubled so there is no longer any reason to make the project easier. However, I'll spread it out more by starting earlier.

Make project better suitable for dividing work between partners

I intentionally did not prescribe much about the internals of the system, to force you to find out by yourself how to best structure the system. However, I'll try to give more guidance on which internal interfaces could be defined to allow more independent work of group partners.

Milestones wrong?

I think the milestones were in the right order, but the spacing was indeed not correct, sorry for that.

Testing

Hmm, I'm not sure. I supplied a shell, which is exactly what we're been using to test your code. The shell does contain all you need. (It would also be fair to say that testing is not the job of the customer but the supplier of the system, even though some manufacturers seem to think otherwise.)

Final word