 Today of class, and mainly what will consume us today is just an open, free-for-all exam Q&A session. So I don't have slides. The slides are online. You know, I think you guys know what you have to cover at this point. I'm happy to take questions. We can review some of the old exams. We can, and again, also to answer general questions about the exam and about the material we covered this semester. Before we do that, it's the last call for the 100-Hundred Club, and happily we have two new groups. Yusuf and Patrick. I don't know if those guys are here. All right, Patrick's here. Yusuf is sleeping, maybe. Yeah, these guys have been in office hours, I think, pretty much continuously since March, so they're done. Yusuf, congratulations. There he is. And Abhishek and Seraf. Are those guys here? All right, one of them's here again. So these were, I was glad I checked before class, because these were like last-minute editions, like maybe an hour ago. So congratulations. That group is now 11. But you guys still have another week. We will hold office hours next week. We're going to shuffle the schedule around a little bit. Obviously, your schedules are different. Our schedules are different. It's exams. But we will do plenty of office hours. And on Friday in particular, we'll do office hours to help you guys sort of wrap up. Okay, so you guys made it to 90%. You can still keep doing the evaluations. There's no need to stop. The 13 people that are left that haven't filled it out, I would still really like feedback from. So I don't know if you guys saw it on Piazza. I just posted one of the short answer questions and the medium answer question for the exam. So you guys have those and can prepare. Look, all bets are off on those questions. You can discuss them on Piazza. You can discuss them amongst yourselves, whatever. The only requirement is, as someone asked, no, I'm not going to give you the answers to. That was a great question. I mean, why not ask? If you don't ask, you don't get. So again, there's no rules about how you guys talk about these. You're welcome to discuss them openly. I would just, again, caution you to... The questions are fairly straightforward. One of them is directly drawn from a couple of the papers that we read. So don't be led astray by the crowd. When you come in here on Monday, you're going to have to write your own answers to be prepared to do that as well. There's no materials allowed for the exam either. So you're going to have to prepare and answer mentally and be prepared to sort of convert it into text on the page that we could read. And as soon as I write the long answer question, I will release it. I have a couple that I have drafted and they're just not quite done. But I will send them out as soon as possible. Hopefully today, maybe not today, probably tomorrow. But as soon as the long answer question is written, I will release it. Okay. Just since we're wrapping up today, I thought it would be appropriate. They're not here, unfortunately. But I sort of wanted to allow myself to thank the TAs for the class as you guys well know these guys, these two men and one woman worked their butt off all semester in office hours, behind the scenes grading your assignments, but particularly helping you out with the assignments. So they really run the class at this point. I just wander into this room periodically and talk for 50 minutes. So they're really doing a lot more work than I am. So I'd like to thank them first. Now I would encourage you if you see them and of course, if you probably will see them over the next week, please thank them. They work really hard to make this course work and they do make the course work, particularly the assignment part. Also the ninjas. So Jerry, Yee Hong, Scott, Doug, James, Carl, Natasha, Sriram, Ryan, and Mack. So these are volunteers. So the TAs get paid. These people are there out of the goodness of their hearts because they want to help you guys do the class. They want to make the department a better place. So I can't say enough about these people. I think they've done a fantastic job. I know a lot of you guys have interacted with them during office hours. So again, please, if you see them over the next week, say thank you. I'm hoping that some of you guys will consider doing this next year and let's give them a round of applause as well. Because the only reason they did this is because I asked them to. They didn't get anything out of it except the fun of reliving their days in this class. Okay, so the exam. Let me just go over the format. It's Monday at 3.30. It's in this room, I think. Can someone confirm that? I think it's in this room. I'm planning on it being in this room. I am not going to give a makeup exam. You're going to get a zero. And I'll release more details about this. At some point, we're going to have to sort of close the exam. So if you don't arrive, probably within an hour, you're going to get a zero. So please come. On the other hand, compare with the midterm. And this is something that you should keep in mind. The exam timing is a lot more relaxed. So I'm giving an exam that is roughly twice as long as the midterm. However, you have over three times as long to actually do the exam. So if we don't get you started exactly at 3.30, just relax. It's not the end of the world. Five minutes here, there isn't going to kill you. Most people have no problem finishing the exam in the allotted time slot. And I also think that's something that's going to allow you guys to do better on the exam. You just have more time. So even if you spend, for example, an hour on the first 10 multiple choice questions and the short answer questions, that still gives you two hours to write answers to three more questions. So I think that you will have enough time and you won't feel the sort of time pressure that you did on the midterm. So I'm hoping this allows you guys to provide answers that indicate what you know and not that you ran out of time or whatever. OK, so the format's a little bit different than the last few years of exams. My only excuse for this is that it's getting harder and harder to write good exam questions. And so I'm reducing the amount of redundancy, particularly for the long and medium answer questions. So this year, the same as last year, same as the midterm, 10 multiple choice questions, six choose four short answer questions. I've released one of those. I've released the medium answer question, but there are no other options for the medium answer question. That is the medium answer question. And then same thing with the long answer questions. I will release one, but you will have to answer both. So in the past, I've written three and you got to choose two, or two and you got to choose one for the medium answer question. I just can't keep going at that rate. A year or two from now, people will hate me because I'll be writing these incredibly inane and complex questions because I'm sort of out of good things to ask about. So by the time you arrive on Monday, you will have seen the medium answer question and a long answer question as well. So the only big surprise is going to be the long answer question. The other long answer question, and then some of the short answer questions as well. So many questions about the format, logistics, whatever. I mean, everything else is pretty much midterm redux. We're doing the same thing. We'll release a seeding chart, blah, blah, blah, blah. Any questions about this? All right. Okay, so at this point, I've got like three or four minutes of material for the end of class. I have nothing between now and then. So I'm happy to ask questions, answer questions. We can go over past exams of which you have access to several. The floor is open. Or if we don't use the time, we can all piece out early, which is also fine with me. What would you guys like to do? Who has a question who wants to go over a question from a previous exam? The only thing I will not do is discuss the questions that were released just to preempt that. Those I think I've given you plenty of help on. Can you discuss them with the TAs? Yeah, why not? And the ninjas as well. I mean, these questions are now publicly available. So go to town for how to sign. Any questions? Yeah, the OS design principles. Uh-oh. Yeah, so who can... Well, let me give you a hint about the OS design principles question. I would suggest that the best source for the OS design principles question is to read the Hintz paper by Butler Lambson. That paper pretty much subsumes the OS design principles that we've talked about this semester. But we talked about, I mean, who can name some of the OS design principles that came up in class? Who can name one? Yeah, Josh. Use of cash. Use of cash. So we had a distinguished speaker yesterday who came in from University of Rochester. Sandy had worked at us. She's a computer architecture person. She works on caches in particular. And her talk was incredibly cool and interesting. It was really sort of bound up in the type of stuff we've been studying. And I discovered something that I did not know, but kind of makes sense, was just that caches, some caches actually have their own TLB. Who knew? So the L1 cache has its own TLB so that it can resolve addresses when it's loaded into the cache. Anyway, so even the caches have caches, right? Like there's no escape from this. The system is a series of caches and one way to make a big slow thing faster is to put a smaller, faster thing in front of it and figure out how to use that thing effectively. But her group has also done work on adaptively sizing cache lines, which if you remember, back to the scaling Linux paper that we read, would allow us to address some of the issues that we faced with false sharing and other types of cache issues. So yeah, so I would refer you to the hints paper for not only for the exam, but just as a general guide to life, right? Just print off that paper, fold it up, put it in your pocket, and just carry it around with you for the next 10 years as you guys write code and build different types of systems and do other types of programming projects that that advice will rarely, rarely ever lead you astray. It'll lead you in a bunch of contrary directions, right? But it won't lead you astray. Other questions? Design principles? So I think I mentioned this before, the exam is cumulative, so it'll cover everything. There will be a slight emphasis, particularly in the short answer section, on things that we covered in the second half of class, file systems, virtualization, some of the papers. Obviously the medium answer question is drawn from the paper that we read, but also has something to do with OS design, so that's a second semester thing as well. Performance analysis, something else that we covered in the second part of the course. RAID, stuff like that. So again, I feel free to ask about anything we talked about this year. I will probably tilt a little bit towards the stuff that you have in mid-testa now, which is the stuff from the second semester. Other questions? Last year's final questions, three and four. Yes, we can. Let me just pull those up so we can look at them together. Three and four. All right. Okay, so three will not be on that. So we did not read the GFS paper. So three won't be on the exam. Certainly not going to ask you about papers. So can we skip that? Yeah, yeah. Okay. All right, four. Describe two ways that file systems compensate for or design around specific properties of spinning disks. For each first identify what the property is and second explain how the file system is designed around it. I'm glad we're reviewing this because I think this is on my list of questions to consider for this year's exam. So sorry, it just dropped off that list of questions. I regularly forget the questions that have been on prior exams. All right, two ways that file systems compensate for or design around specific properties of spinning disks. Who can do one? Yeah, Josh. What's that? Yeah, so remember the idea of cylinder groups. So a bunch of file systems tried to do layout that reflected the fact that seek is slow. Seek is the thing, moving the heads back and forth is the thing that really dominates latency on spinning disks. So a number of file systems tried to had features that were designed to try to incorporate this. So FFS introduced the idea of cylinder groups. So I'm going to try to locate related files together or related file metadata together. Now EXT4 still reflects some of these features. So what's an example from EXT4, if you guys remember, the file system feature that reflects seek times. What does EXT4 do that directly reflects something about the fact that seek is slow? It's similar to cylinder groups. Yeah. Yeah, it's not quite that, right? So remember, EXT4 breaks the disk up into these pieces. And each piece has an area where it has a file system metadata. And ideally EXT4 is going to try to use that metadata to, it's going to try to attach the blocks that are located in that group to that group of metadata. So remember, each sort of I'm blanking on what the name is, but each little sub-disk had things like inodes, had an inode map a block availability bitmap. So if I'm going to allocate a file, I'm going to allocate the inode and hopefully I'm going to allocate the data blocks in the same group so that the goal is that the data blocks are close to where the inode is located. So that's one way that EXT4 did this. What's another? This is probably the harder part of the question. Yeah. I don't even know if that's in the answer, but that's a good answer. It takes a long time to position the disk to read or write data. So by the time I've done that I don't necessarily want to read or write the smallest amount of data that the disk can support. Particularly as file sizes have grown I don't want to take all this time to move the head all the way over somewhere and then only pick up 256 bytes of data. That doesn't make any sense. I'm trying to find out if the large number of disk channels or multiple megabytes may end up consisting of a bunch of different 250 bytes blocks that have fragment and end up all over the disk. So EXT4 and even FFS incorporated this larger block size of 4k and more farther file systems have made it even larger. I try to allocate large contiguous areas to amortize the time it takes me to get the head there, get the data under the head, and then I can read a whole bunch of it all at once. What's another feature of spinning disks? You guys are thinking about internals. Yeah, we're thin interface for reading and writing. What's that? OK, yeah. So I think we would accept that. The disk interface is terrible. The disk doesn't know about names. The disk doesn't know about directories or whatever. All of that stuff is built on top of a very low-level read and write block interface that the spinning disk provided. What else? Yeah. Oh, yeah. Now you're thinking to terrible FFS quirks. Yeah, so remember FFS did that thing where it would skip blocks on the disk because the bus couldn't keep up? Yeah, that's terrible. How about stuff that survived until the modern day? That's a good answer, guys. I always hate thinking about that because it's just like this dark past. It's like the middle ages of disks. Yeah? Have you heard of it? Yeah, disks fail. The spinning disk is a physical device. It's the only part of your computer that you can break by dropping it. Not going to break it. I mean, you might break memory by dropping if you drop in the right way or karate chop it or something weird, but in general, it's the most flimsy part of your system. It's spinning, things are really close together, and so jolting it, dropping it, it fails. It wears out, things are moving, wears out a lot faster than silicon electronics, which, I mean, I'm assuming that transistors wear out eventually, but I don't know anything about it. Talked to somebody in EE, but I assume they don't last forever, but they certainly last longer than something that's spinning around at like 10,000 RPM. So all of the consistency things we talked about with disks, everything that disks do to try to survive failures, faults, sectors, dropped sectors, stuff like that. All of these features of disks that are there because they are physical devices. I think that's enough, but that's a good question. Other questions? We can do other questions from this year's exam. We can do questions from other exams. Anything else? It's a good question. I would expect you to understand the papers to the level of detail that we discussed in class, but I don't think it would hurt to read them and find out a little bit more about them. But I'm not going to ask you about the details of some. In class, when we talked about the research papers, intentionally we focused on why the motivation was what the big design changes were, things like this. We didn't get into the nitty gritty of how, for example, exo-kernels move data between the exo-kernel and other parts of the system. And if you look at those papers, if you look at Zen and the exo-kernel paper in Atlantis, there's all these sort of gory implementation details that are super interesting if you're sort of a hacker person, like a lot of us are, but not the type of things I would ask about on an exam. So I'm not going to ask you how the IO rings that Zen uses work. I don't even understand that to be honest. That's a good question. So I think how about this? How about if we agree that watching the videos and absorbing the discussion in class should prepare you to answer the questions about the research papers? Other questions? Yeah, what's that? Yeah, sure. Yeah. So I have to warn you, I like the long answer questions. And every year, there is always a long answer question. You know, one of the things I want to do with the exam is give you guys a chance to tackle an interesting design problem that's related to computer systems. And so there's always one or two long answer questions. Some of them are somewhat processing stuff that we've learned, but there's usually one where I ask you to sort of think about a new design problem and provide a solution. So let's look at, let's see, which one of these is a good example. Yeah, OK, let's talk about this. This is a fun question. So essentially, what this question says is, look, for a long time, we've dealt with the fact that we have this trade-off between performance and durability. Memory is fast, not durable. Same thing with cash as in other things. Stable storage, durable storage, whether it be for long-time disks and now spinning disks and flash, have been slower. And that's been something that sort of created the storage hierarchy that you guys know and that you guys have on your machines. However, there is research, sort of hardware research going on that could potentially lead to having storage that is as fast as memory, but persistent. So imagine if flash were as fast as your DDR3, DDR4, DDR68, whatever, memory. And so the question was, how does this change the design of computer systems? So this is present and motivate five different significant aspects of OS design that you would reconsider if you were designing OS for a device with a single, large, and fast byte addressable NB RAM chip replacing both memory and the disk. So essentially, you can think of this as a system that has no disk, quote unquote, but just a huge piece, like a multi-terabyte piece of something that's as fast as memory, but does not ever lose its contents. So what's one? Well, a virtual memory goes out the window. Well, what part of virtual memory would we not need to worry about anymore? Yeah. There we go. No disk to swap to. That's awesome. So there were a couple of answers to this question that were essentially just kind of like parts that you could now kick to the curb, like swapping, gone. What else can I kick to the curb? So there's aspects of linking and loading that could be very interesting. So load-elf, what does load-elf do? Load-elf is designed to take this blueprint that's in a file. Why is the blueprint stored in a file? Because the files are persistent and memory is not. So load-elf is supposed to take this and move it into memory when the process is run. Why do I do this when the process is run? Because until then, I don't want to use the memory for it. But now I don't have this distinction anymore. So Isaac makes a great point. It's just sitting there. The program is just sitting there at any time. Now, so load-elf might become as simple as just copying. So load-elf kind of starts to look like fork. I already have an address space set up for this process. It may not be running. It's just sitting there, dormant. And instead of using load-elf to move stuff from the disk to the address space, I just call fork to create a new copy of the address space. So I need a copy of the address space that's sort of at t equals 0. I need a copy that represents what should start to happen when this process starts to run. But I can just have that address space sitting there. And then I call fork and let it start executing. And that's sort of how things work. So that's a great point. What else? What else can I do? Yeah. Well, remember, I don't lose this memory. This memory is persistent. So if I shut the machine down and power it back up, everything's just the way that I left it. But remember, again, I know it's hard to wrap your mind around. It's hard for me, too. This was like four years ago. I was at Hado West at someone present this paper. And it's like, it just really blows your mind. It's like you have a huge chunk of memory, multiple terabytes of memory, but it's persistent. It does not lose state when the machine powers down. So yeah, so this is great question about in a system like this, what does it mean to reboot? On a normal system, rebooting or having the power pulled out resets the contents of memory. Now, on some level, that's a pain because the OS does all of this work to unboot, which takes a few minutes sometimes, to essentially use state sort on disk to reconstruct the memory state that's suitable to sort of boot the system until it do whatever the system does when it boots up. So the system does the same thing every time it boots. But because the memory is wiped, it has to sort of go through this routine of loading things from disk. But now I don't have a disk. The memory doesn't get wiped. So on some level, this is sort of a trade off here. So what's good about this? There's both good and bad sort of aspects to this change. What's good about it? Yeah, what's that? Oh yeah, so again, this system has a single store. I don't know what to call it because if you call it something you guys are used to hearing about doesn't make sense. You can think of it as a single store that's persistent but as fast as RAM. Now you're still probably going to want to have caches because caches close to processors still make things a lot faster. So you can still assume your processor has an L1, L2 cache. Well remember, in order to have a cache, there has to be something bigger underneath it. This is the bottom. If I have a terabyte of memory, I don't need any more storage or 10 terabytes or whatever. Maybe I still have this huge chunk of fat like a two exabyte drive where you store every frame that's been captured by your Google Glass or something like that. Who cares? But that can be off device. Again, I have imagined two terabytes of RAM that does not lose its contents when the device reboots. So in theory, again, what's good about this from a reboot perspective? Right. So yeah, it's impossible. But you're getting to the root of what's both good and bad about this. The problem is rebooting doesn't reset anything. So good news is I don't lose data. So what is one thing that this should allow me to do better than I can do today? Yeah, so that's a great point. This makes sleep trivial. I just need to make sure I stop things cleanly and then the device can. So this device is going to sleep like a champ. And yeah, power off, power on. Under normal operating conditions, this is the smartphone that runs out of batteries. But then you plug it back in and the screen just comes back up. And your apps are all just sitting there as if they were nothing. So power off is really nice. Yeah, so that's the bad part. The bad part of rebooting is one of the reasons that systems reboot is something went wrong. And rebooting helps me get back to a good state. So there's some bug in one of your programs or in a bug in the OS. Let's focus on the OS for a minute. And failing in rebooting allows me to sort of reset the system and clear out somehow, again, somehow I got to this bad place. I went down a series of paths and maybe it was caused by a series of really weird race conditions that the user did something funny or a device was misbehaving or something. But I got into this state that I didn't want to be in. And so despite the fact that it's super drastic, rebooting allows me to say, start over. Just clean the slate and I can start over and we'll see what happens again. And I'll try not to do that again. This system doesn't really have a concept of doing that. Yeah. Yeah, so that's another great point. I mean another reason systems reboot is because they run out of memory. And so that's another case where I made these mistakes over time and they sort of built up over time and then eventually I didn't have any memory left over. And the way to get back to a known good state is just to reboot, right? To just state every process, start over. And then you can start leaking memory again. But if I reboot periodically, so actually just anecdotally, we recently had a problem with one of our phone lab machines and I actually had to come in at 3.30 in the morning and power cycle the VM host. And it turned out that as soon as I did that, the whole machine got a lot faster. So I had this theory that the VM host was leaking memory slowly for months and things were just slowly degrading over time. And then finally power cycling, it caused the VM host, actually the hypervisor, the VM or hypervisor to go back into a better state. So anyway, even hypervisors leaked them. That's my theory though. I am in no way imputing VM wear on the software. Yeah, what's that? Well, I mean we could still do a scheduling in the old fashioned way. I mean scheduling doesn't really have to change. The real change is sort of to destroy a tyrant. But what does this allow me to do? Let's come back to reboot. So bad thing is it's not clear how I can sort of unwind mistakes because wiping the memory is this really sort of dramatic action. But it tends to work. I mean it's a big step, it's a big hammer. You have to hit the machine with and it's frustrating because it takes a minute to come back up. But when it does, things are usually better. You've managed to sort of clean out the system and give it a fresh start. So we may need to find a way to redo that. Now on the good side, what is something I can do with this machine that I really can't do on a normal machine as far as reboot? So let's say I've got 10 applications running and the kernel hits some sort of fatal fault. So what should I be able to do here that I wouldn't be able to do normally? So normally on a normal machine, the application is using RAM and the kernel is using RAM. And in order to get, now of course, the kernel, I'm not going to make very much progress with the kernel that's hit some sort of fault. That's why the machine usually starts over immediately. What can I do here? Yeah, so I should be able to reboot the operating system without affecting the state of any applications. So it's kind of like apps are running. They're making system calls. And then suddenly, there's this little pause. And then they just keep making system calls and everything goes along. Now the problem is, of course, there might be some state that the application is relying on the kernel to keep, like its file table. But you can imagine designing an application so that there is now a signal. Wouldn't this be awesome? A signal that the application gets that says, the kernel just rebooted. I don't know what's going on with you, but I just powered off and restarted. So that file table that you were using, I forgot all about. So you might want to reopen those files that helped me out because I don't know what file handle 4 is anymore. I knew a second ago, but I forgot because I've been restarted. So that's another example. Yeah, so I mean, you can try to, well, OK, remember, there's no disk. So I mean, you should be able to soft reboot the kernel. But again, the problem is the kernel has state about applications that may or may not be easy to save. And actually, there's quite a bit of that. There's page tables and other things. But in theory, I might be able to reboot the kernel in a way that preserves as much application state as possible while allowing the applications to continue to run. Normally, you don't care about this, right? Because you just think, look, the kernel rebooted. If the kernel reboots the machine, everybody loses all their state. And so who cares, right? The application can't keep running because all of the state that it had in its own memory is gone. So again, who cares at that point? But now, because I have this persistent memory store, it's possible that I can soft reboot the kernel without affecting everything else. Any other questions about this question? This was a fun question. No, but this is a problem file systems already have, right? I mean, the idea of a file. So one of the things that's really interesting about this, of course, another change here is, normally, I've got memory and I've got a disk. And I might use part of memory for pages and part of memory for the cache. And we talked about how those two can flick with each other. And I might use part of the disk for my swap file and the rest of it for file systems. That's usually static. So usually, on Linux, there's a swap region that's just defined on the disk. There's no file system loaded on it, and it's just initialized, and it has some maximum value, and that's where things go. And the rationale is that it doesn't actually take up that much room on the disk. And so the rest of the disk I use for my file system, and I don't really miss that chunk that I use for swap. On this system, everything competes for storage. Now, what's one thing that I just mentioned that we can get rid of now? One of our uses of memory is no longer needed. I don't need a file system cache. The whole file system is in memory. That's awesome. So the file system cache can be dumped. But in the swap file, somebody already pointed out, I don't need to swap, so that's gone. But now I have a system where I have a file system that competes for space with memory. So process pages are now competing for space in the same chunk of the store, what do you want to call it, that's going to be used to hold the file system. And there are certainly aspects of file systems that you would probably want to rethink if you design them on something that was as fast as memory. Yeah. Yeah, that's one of the right buzzwords. There's a bunch of different names for that technology. And again, I am not an electrical engineer, and so I don't understand it, but I think it's awesome. I hope that somebody actually solves that problem so we can use it. Yeah, so that's another great point, which is that in a lot of cases, kernels can sort of tell when they've messed up. Like I had an assertion, like your own kernel has done this all the time. A kernel panic is caused by a state that the kernel cannot recover from. And so it'll just die now. But there are times actually where the hardware has to get involved. So most systems have sort of hardware mechanisms to reboot the system if the OS gets wedged in a way that it doesn't understand. So for example, an example of this would be a watchdog timer. So certain types of systems have, the hardware requires that the system repeatedly write into a register. And if I don't write into that register for a long enough period of time, the whole system reboots because it just thinks something went wrong. So yeah, that's a great point. I mean, how do I handle cases where the OS is broken, the hardware can tell, but without this memory, without this mechanism being able to wipe memory and reboot, I may be hard to recover. Now of course I can still kind of get the same behavior. So for example, I could build a system like this by just partitioning the store so that a certain amount of it was memory and a certain amount of it was the file system. And then I could treat it very much like we treat systems today. So when I quote unquote reboot would involve zeroing out that whole part that was memory and then sort of essentially emulating the behavior of a bootloader. So I can refill that memory space with contents that are in a known good state. It's a cool question. It's too bad I used it last year. So any other questions? Okay, I just have a couple more slides, slides. All right, so the next part of the, just to finish up, what do you do now? So in a couple of weeks, you're gonna have like this enormous amount of free time and maybe next semester if you're still here. So I just want to sort of introduce you to some of the options that you have now that you've finished this class. So there's a bunch of other good undergraduate and first year masters courses in the department, particularly for undergraduates that are gonna be here next year. I've really been trying my best to get this course into the curriculum earlier because there's a lot of cool courses that, because this is traditionally been a senior level course or whatever that means, people haven't been able to take, right? So for example, there's a cool class on OS internals with Ken Smith. So he's one of our IT staff in the department, but he's also done a lot of work on BSD and he teaches this course in the summers. So if you're around, that's a very cool course. I know it's being offered this summer as it usually is. Next spring, Oliver Kennedy teaches a course on database programming that's also quite development heavy, but databases, I think compared to operating systems, databases have a lot more sort of theory to them and there's some performance challenges and things like this. So this is a course that you guys might enjoy. Distributed systems, which is taught in both semesters, fall and spring, fall by Marat and then the spring by Steve. That's the class that's been in this room before we get here. This is really sort of fast forward into the 90s and the aughts, right? So this is actually how we build systems today. And you'll see there's a lot of interesting new sort of theoretical ideas and new ideas about how to build systems that emerge when you actually try to program a bunch of systems at once and require that a bunch of systems work together. So this is fun. Networking, another very cool course taught. I don't know how they're gonna structure it. It's normally taught in the spring by Demetrius. This year he taught it in the fall. I think next year he's back to the spring, so Chen Ming will teach it in the fall. Regardless of who's teaching it, another very fundamental aspect of how computers work. I mean, I think all these courses should be required because this is the present. This isn't even the future. This is just how computers actually work. Yeah, yeah, but people like that, right? That's why they took this class. So yeah, 489, 489 and 462, and to a certain degree 486, depending on who you take it with, will also give you a great chance to do more programming and to do some fun assignments that require you to write code, which is something that some people enjoy. And also, of course, as you know, programming is a skill. The more you do it, the better you get at it. Okay, so if you are an advanced, and I don't wanna say graduate student, because I would be happy to try to figure out how to get undergraduates into these courses if you guys are prepared for them. This is the course on advanced computer systems in the fall. That's taught by Kartik and Steve. They do primarily sort of Android smartphone work. So they have a bunch of cool projects you get to hack on, you get to hack on sort of Android internals and sort of apply. And again, I think that course is quite related to what we did this semester. So there's a lot of nice OS design principles. I am teaching a seminar in the fall, particularly for PhD students or any master's students that are PhD curious. And so we're gonna be building, continuing to build a system that some of my students have been working on that's very cool and that we're gonna probably roll out this summer that's allowing programmers to express development time uncertainty. So write code that's more uncertain and that can be adapted at runtime. So this is sort of what's happening course-wise. So I hope that next year we will continue the tradition of having a large and enthusiastic group of ninjas for this class. I know that there's people in this course who will get an email from me asking them, begging them to help out just a couple hours a week like the National Guard. A couple hours a week, a couple weekends a semester and you can be a ninja for this class. And again, I mean, I think this semester having a big group of volunteers really helped make the class work a lot better. So I'm hoping that some of you guys will be able to do that. I will also point out that you will discover and I'm sure the ninjas in this class will agree with me that you do not really understand these assignments until you try to help somebody else do them. You think, oh, I got it to work. I got 100 out of 100 or whatever, fantastic. Try helping somebody else get to that point and explain to them how to do this. That'll actually help you sort of understand these things at a much better level. And finally for graduate students, I'm always looking for talented students to work with me. Also for undergraduates, I've always had some undergraduates in my group doing various projects. So if you're around next year and hopefully for years to come and you're curious about this, this is sort of like step. Doing well in this course is sort of step one in the process of starting to get to the point where you could work in my group. All right, so yeah, exactly. And maybe this will lead you down the path of becoming a systems researcher, but I hope at least what we've been able to accomplish this semester is giving you guys some guidelines and help you to improve as programmers so that you build better computer systems and just build whatever you build in the future better and have a little bit more fun doing, all right? So we're done, I thank you guys for a great semester. I think this has been a really talented class. I've had a lot of fun. I wish that I had a chance to get to know some of you guys better, if you guys are around next year, please stop by and say hi. Good luck finishing up assignment three. Good luck on the exam. I will see you guys on Monday. Have a great weekend. Thank you.