-2

When I was a computer science student at my university, I wanted to delve into the code of operating systems. I was (and still am) attracted to such software and hoped for a course project that allowed me to add or modify some code to it.

Unfortunately such course project never happened, so I thought that maybe I could do something similar in occasion of my BSCS thesis.

Once I completed all my courses, I started googling the web looking for a specific topic or argument about OS to discuss for my thesis.

After some searching, I found a thesis discussed by a MS graduate in computer engineering: it was about operating systems reliability.

More specifically, this thesis discussed an implementation of a monitor that could detect faults triggered by faulty device drivers due to their bad programming. The candidate implemented this monitor by modeling a finite-state machine of the disk device driver and then implementing the monitor based on such FSM with a specific scripting language. Finally, the candidate measured the overhead introduced by this monitor of his creation.

This thesis impressed me and I hoped that I could do something similar, so I started asking my operating systems and computer architecture teachers about it. In particular, I consulted these two teachers of mine:

Teacher 1: this teacher taught me the lab part of the computer architecture course, where I programmed in assembly language and even made an (simple) exercise about I/O programming. He also taught me the fundamentals of I/O like interrupts, isolated-I/O, memory-mapped-I/O and I/O ports. When I showed him the thesis I found, he said that such a thesis was possible only for computer engineering students for the following reasons:

  • There's hardware;
  • The computer engineering programme has more credit hours of operating systems than CS does;
  • Knowledge about automation is required.

Despite these reasons, I explained him that I found the knowledge required for interpreting this thesis on the Tanenbaum's computer architecture book that we used to study during our CA course, but then he replied me that "Computer engineers students study from the Tanenbaum's books too". Then I recalled him the exercise about I/O programming and the fundamentals about I/O he taught me and said "That's just to show".

Teacher 2: this teacher is a computer engineer, from his BS all the way up to his PhD and teaches the computer architecture and operating systems course.

When I showed him the thesis, he said that I couldn't do anything similar because it was more hardware-related.
He then said

"If you were going to develop a gps navigation software, would you care about the computer on which this software will be run?"

I was to reply with a "Yes" but he immediately changed the example:

"If you were going to develop a gps navigation software, would you care about the shock absorbers?"

I was going to reply with a "No, since the shock absorbers do not provide any relevant information about geolocalization" but I preferred not to rebut.

"In order to develop such a thesis, you need to know everything about the device. This is the reason why such thesis can be discussed only by electrical engineers"

he said, but when I pointed out that the thesis was made by a MS graduate in CE he replied

"The candidate of this thesis is a liar!".

In the end of the conversation, before I left his room, he stated that

"Java is taught to CS students because they must not know what's underneath it!".

With this thread, I don't want to blame these two teachers of mine, I only want to know if there's something questionable about what they said to me. Were they thoroughly right?

Since then, I've made searches on the web and found projects and even theses of CS students that were about device drivers development.

I feel that I could have done such a thesis but my teachers weren't skilled enough about that topic. But am I right?

I'm not a CS educator, and this is the reason why I've written this thread: I want to know your opinions.

migrated from cseducators.stackexchange.com Sep 2 at 11:50

This question came from our site for those involved in the field of teaching Computer Science.

  • 5
    This is much more a rant than a question. – Buffy Sep 2 at 12:37
  • In the 1970's I became project leader for the core of a proprietary operating system, including I/O and device drivers. I had a master's degree in CS, no computer engineering education. Of course, I had to learn on the job, but that is normal. – Patricia Shanahan Sep 2 at 13:13
  • 1
    I expect your teachers know about the specific requirements of the research component of your degree, and they understand it to mean more of a focus on software. At other universities the requirements may differ, which is why you've found theses of computer science students with more of a hardware focus. – Emma Sep 2 at 13:25
2

At my university the rule was "They have to give you a thesis, but they have to right to decide the topic". So, there are two possibilities, either your topic was just not in their field of interest. Which is ok, why should they provide time and resources to further a topic not of interest? The other explanation is, that your topic is not "hard enough" in a scientific sense. So if it is too easy, like "i just wanted to delve into code and do something" then it usually is not scientific enough. Research has to further the known area in some kind of way. Just doing what everyone before did is not enough for a degree.

That said, i highly doubt that the professors are not skilled enough for the topic. I rather suggest, they know enough not to waste time on that topic. That other students on other universities did these thesis does not really say anything. It all depends on the time, the place and the area of interest of the professor, the student, the research and everything around.

The way i would propose to handle this, is to ask them what they would offer you knowing what you would like to do. Maybe there are topics interesting to both sides.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy