Staff / Meeting Schedule / Textbooks
See the course home page.
Grading
Unless legal action is taken against me, I won't have a standard formula for grades. Everything counts; nothing is fatal.
The goal of the course is to help you have an understanding of operating systems by the time the course ends. The goal of the final grade is to reflect my confidence in your understanding. With that in mind, the fact that you didn't know what EDF meant on a mid-term is of little importance if you do at the time of the final.
The goal of this approach is to be more fair, and to emphasize learning rather than test taking or spending hundreds of hours on each assignment. On the other hand, it's quite subjective, so of course some quantitative measures will be used. As a rough guideline, in the absence of all information about you (for example, I have no idea who you are when I see your name on the grade sheet), the weighting will be roughly 30% for the two midterms, 20% for the final, 40% for the projects, and 10% for the homeworks.
Overall, I'd be happier knowing you really understood some things in depth, having thought about them beyond the bounds of the course material, even if there were other things you weren't so versed in, than to have a shaky but even understanding of everything. If you have a solid basic understanding, when you need to understand something in the future you'll recognize that, know how to find out what you need, and manage it without problem. If you never really understand the foundation, though, what you'll know is just whatever remains of the course facts, which is much less valuable.
Exams
There will be two mid-terms and a final.
Final exam: 2:30-4:20 p.m. Tuesday, Dec. 12, 2000.
Homeworks
Reading and textbook-style questions will be assigned with some regularity. For instance, here's the first assignment:
Due: Thursday before Section
Read Chapters 1-3 of the Silberschatz book.
Do questions 2.8, 3.7, and 3.12 from that book.
Read Chapters 1 and 2 of The Linux Kernel.We reserve the right to partially grade such assignments, including the extremes of grading all the questions and grading none.
Programming Project
This is a "project course," meaning that part of its role in our curriculum is to give you significant programming experience.
The course has traditionally used a hardware/OS simulator as the basis of the project. There are many pluses to doing so. We won't be doing that, though. Instead, we'll be hacking the Linux kernel. (For you purists, the latest, "beta" version.)
Here are the major reasons to try this:
- "Because it's there"
- When you're done you'll know you know something about operating systems, not about simulated operating systems.
- The Linux code contains (at least) one answer to any question about OS's you might have. If you want to know about how something is done, you'll know how to find out.
- The "Linux code" includes a fairly sophisticated program development infrastructure. Exposure to that will do us all some good.
This last point is very important. The projects will be designed to require much more reading of code than writing. The project descriptions will not give away every detail - the projects are, in part, just excuses to have to look at the code.
All that said, kernel hacking is fundamentally different from application code hacking (which is one of the points). For one thing, the consequences of having a bug are much more serious. At the same time, the debugging infrastructure is much more crude. Also, the run->bug->edit code->recompile->run sequence takes a lot more time, because running the new version requires at least one reboot of the machine. Occasionally, bugs will blow away the system, and you'll have to reinstall. All of this places a premium on thinking about what you've written, and understanding how things work, rather than just trying out potential fixes as fast as you can (as that will not be very fast).
Operating System Theology
There are three major OS sects:
- "Windows sucks" (Believers usually are wildly enthusiastic about either Linux or MacOS.)
- "OS == Windows" (and the radical "What's good for Microsoft is good enough for me" sect)
- "You ignorant snots, the future is JVM"
Due to state and federal law, we won't be getting into theology in this course. But, if you're a Windows-hater, hey, we're using Linux. If you're a Windows-lover, you'll be pleased to see what the Linux code looks like.
Working on the Project
We'll be using the Special Projects Lab, Sieg 231. A special configuration has been set up so that having a room full of hacked kernels, and people all operating as root, won't be a security hazard we can't live with.
If you want to work from home, there are two possibilities. First, you MIGHT be able to login to our systems remotely and get something done, whether from a home Linux or Windows (or Mac) machine.
Second, you can run Linux at home. This is a bit tricky though, even if you're already running Linux at home. The reason? As you hack the kernel you can't be sure that your code won't completely snuff your file system. (This is true whether you dual-boot with another copy of Linux or with Windows.)
I wouldn't try to do the work for this course dual-booting from a drive on which I had files I wanted to be sure to have come New Years. If you really want to work at home, and don't have a machine to devote to this, I'd get a separate hard drive. I'd install both some released version of Linux on it (to have a stable kernel for development purposes) and my test kernel. If my BIOS allowed it, I'd just switch the boot order of my hard drives between this "test system" and my regular system. (And I'd be sure my "production drive" wasn't anywhere to be seen while running off my "test drive.")
(I'm actually doing this with a machine I have at home, but my BIOS doesn't allow that level of control. Instead, I physically unplug the drive I don't want to be using. There's an unusual amount of wear-and-tear in this, though, so be careful.)
Course Mantra
As mentioned above, you'll be dealing with a lot of real-life artifacts. This is bound to cause considerable frustration.
When you're feeling that you simply can't take another second of winding through the Linux maze, or the makefile maze, or the out of date or incorrect or missing documentation, my suggested phrase for use in this course is "bloody hell." That's it, just a simple "bloody hell." It's strong enough to smooth the psyche, but rare enough in these parts that it shouldn't offend anyone.
My backup mantra suggestion is "sacre bleu" - unpronounceable, and so less satisfying, but completely inoffensive.