Teaching

Engineering Trustworthy Software Systems / YS16b@DIT

Trustworthy software systems are correct, robust, secure, and reliable. Correctness means that the system functions according to a given specification, without errors under regular inputs; while robustness refers to correct behavior under unexpected, but benign, edge-case inputs. Security, on the other hand, means that the system maintains its confidentiality, integrity, and availability in the presence of adversaries who are actively trying to compromise it. Finally, reliability means that the system can withstand unexpected failures and continue operating without disruption. (But you already know all these from K22!) Today, with the increasing rise of GenAI, it is trivial for anyone to produce vast amounts of software, starting from a fuzzy specification in the form of a natural language prompt, to thousands of seemingly-functional lines of code within seconds. However, the core question is how to assess what such software systems can actually be trusted to do. The goal of this course is to discuss techniques and ideas from relevant scientific domains and literature, and help pave a principled scientific avenue for engineering trustworthy software.

Guideliness

In the context of tis course you will need to read papers (and understand them), as well as present and judge them. The tentative list of papers for Spring ‘26 is here.

How to read and understand a paper, and give scientific feedback on it.

1) Start with the title and conclusion and focus on the main idea

  • Do you understand what the target problem is?

  • Do you understand what the proposed solution is, at a high-level?

2) Continue with Related Work

  • Do you understand what is allegedly new compared to previous work?

  • Is it a better solution? If so, how?

3) Move to the Introduction

  • Do you understand the motivation of the work? (Usually on the latter part of the intro.)

  • Do you understand the alleged contributions of the paper? (Usually on the latter part of the intro.)

4) Go to Background (if one exists)

  • Do you have all the necessary vocabulary to follow the rest of the paper?

5) Go to the core of the paper

  • Do you understand what the core pieces of the proposed solution are?

  • Do you understand the challenges, if any?

  • Do you understand the design goals, if any?

6) Go to the evaluation

  • Before starting the evaluation section, step back. Do you have a minimum set of questions you would like to see addressed in order to be convinced that the proposed solution does what it promises to? Read the evaluation with those questions in mind.

  • How do you feel about the breadth of the evaluation? Are all significant angles examined?

  • How do you feel about the depth of the evaluation? Are the questions answered through comparisons against strong baselines?

  • How do you feel about the statistical significance of the results? Are the results positive because the comparison points are cherry-picked? Or are they conclusive enough?

  • If the solution involves multiple components, do you clearly understand how well (or poorly) each component contributes?

7) Re-read the paper linearly from the beginning. The following must be clear:

  • Again: What is the target problem?

  • Again: What is the proposed solution?

  • Again: Why is the proposed solution different from the state-of-the-art existing solutions? Is there a real delta, or is it too incremental?

  • How well does the proposed solution work based on scientifically valid comparisons against strong baselines? Strengths? Weaknesses?

If all the above checks out, lastly, ask: Does this work stand a decent chance of being adopted in practice? Always remember to be positive and professional, reinforce positive and objective energy to the community, and give constructive feedback.

How to make a great presentation (and enjoy it).

1) Start your talk by saying: “Good morning / afternoon / evening, I am X from X University, and today we will discuss our work on X.” Keep it simple and move on. Do not spend time at the beginning talking about your full resume, your university history, or unnecessary background about yourself. (This is banal and signals to the audience that something boring is going to follow!)

2) On the second slide, motivate the importance of the problem using high-level information your grandparents will understand.

3) On the third slide, introduce the solution by clearly explaining the limitations of past approaches. The audience must understand what did not work before so that they appreciate what’s new.

4) In the background section, do not write math or long descriptions. Instead, include a slide with a concrete, working example.

5) If applicable, include an architecture overview slide with a drawing that shows all components, and how they connect.

6) For the evaluation, start with one slide that lists all research questions and explains the experimental setup. Then dedicate a separate slide to each question, with the question written in bold at the top and the corresponding graph shown clearly.

When presenting graphs, animate them. First, show the axes and clearly explain what the x-axis and y-axis represent. Pause. Make sure everyone understands what is being measured. Then reveal the plot or line and discuss the meaning of the results.

  • Avoid busy slides and long sentences and estimate roughly one minute per slide.

  • Don’t look at your slides — look at your audience. Make sure you don’t lose them: be interactive and ask questions throughout the talk.

  • When people ask questions, it is perfectly fine to ask them to rephrase if something is unclear. If you do not know the answer, say: “I need to think about this — let’s take it offline.”

  • Always begin answering questions with: “Thank you for the question.” Then repeat the question to confirm alignment before responding.

Breathe well and speak slowly.** If you feel stressed, do not speed up — slow down and take deeper breaths. (You can gain time — and air — by asking, “Is everything clear so far?”)

Always include a final summary slide with three to four bullets summarizing what was discussed. The last bullet should say: “Thank you! Questions?” Leave this slide on the screen, smile at the audience confidently, and enjoy the applause!

How to write a great project proposal (based on the Heilmeier Catechism).

1) What are you trying to do?

  • State the objective clearly and simply, and define the problem and the intended outcome in plain language without jargon.

2) How is it done today, and what are the limits?

  • Briefly explain existing solutions and their shortcomings.

3) What is new in your approach and why do you think it will be successful?

  • Explain your innovation and why it will work.

4) Why does it matter?

  • Explain the impact and identify key stakeholders

5) If you’re successful, what difference will it make?

  • Define clear success metrics and use concrete outcomes (e.g., “reduce cost by 40%,” or “increase detection accuracy to 95%”).

6) What are the risks?

  • Identify what could go wrong.

7) How much will it cost?

  • Define cost in money, resources, or equipment needed.

8) How long will it take?

  • Define a clear timeline.

9) What are the midterm and final “exams”?

  • Define how progress will be measured and come up with clear checkpoints that could signal when / if things go south.

Logistics on Grading

  • Group project: 50%
  • Paper presentation: 10%
  • Class participation: 10%
  • Midterm exam: 10%
  • Final exam: 20%

Operating Systems / K22@DIT

Operating Systems: Internals and Design Principles

A pdf with all slides presented on Fall ‘25 will remain publicly available here as well as a review google spreadsheet summarizing how people felt about the class.

Summary

The goal of this course is to provide a hands-on introduction to Operating System (OS) internals and design principles, and to help you understand what is really happening when you execute a program on a machine. On the plus side, core OS abstractions, such as processes and threads, and OS primitives, such as locking and Inter-Process Communication (IPC), are ubiquitous in any software stack. Furthermore, the complex and architecture-dependent management of hardware resources performed by the OS is implemented following traditional design principles and optimization patterns that are useful in engineering any software system.

Rationale

The idea that software engineering is about producing vast amounts of source code was never a good one, and now, with the prevalence of Generative Artificial Intelligence (GenAI), it is finally coming to an end. What matters is principled understanding. To this end, producing small portions of code, but being able to quickly navigate and understand large code bases – potentially written by various people and different teams – is of paramount importance. Working with OSes, and more specifically with OS kernels (such as the Linux kernel), is an excellent playground to master the aforementioned skill. You cannot copy-paste code repeatedly and hope for something good to eventually happen. Instead, you need to understand the rationale behind the structure of software, abstract portions irrelevant to your goal, focus on the relevant ones, and spend your energy there.

Syllabus

The course will revolve around questions regarding the following topics

Open door policy

  • Whether you’re a colleague or a student, you’re always welcome to stop by for a chat, a question, or to just say hello.

Similar OS courses

Textbooks

Source Code Reference

Acknowledgments

This course, and especially the programming assignments, are heavily inspired by the OS course taught at Columbia University by Jason Nieh. Jason’s class (COMS W4118) was the first to introduce virtualization as a tool for teaching operating systems. During my time at Columbia, this class changed my perspective on how working with any software systems should be approached.