All right, welcome everybody to a new term. We seem to have somehow managed to get 292 people so far on the Zoom. That's pretty impressive.
I'm going to be basically lecturing twice a week from here. Hopefully this will work out well. Feel free, I think, to avoid the chaos, let's have people type their questions in chat. I have two screens so I can kind of watch. And let's just see how this goes, if everybody's ready.
So, welcome to the virtual version of CS162. I guess since we talked about virtualization, this is particularly appropriate. Can I get a couple of thumbs up or something in the chat just to make sure that... The sound is good with everybody. And please disable your cameras if you could.
All right, great. So my name's John Kubitowicz. I'll introduce myself a little bit later.
But today, what we're going to do is we're going to dive right in and ask some questions, like what an operating system is, since you guys are taking this class in theory. And maybe we'll say something about what it's not. We're going to try to give you some ideas of why I find operating systems so exciting.
And, oh, and we'll tell you a little bit about the class, but let's dive right in before we get to the operational parts of the class. And I want to point out that interaction is very important. This is going to be kind of hard.
Even when I teach live normally, the interaction portion of this is challenging on the first day. But once we get into the second day, I think. or a second time, I think we should be able to ask a lot of questions.
It'll be great. So there was a question about whether slides are going to be posted. Yes, we're going to post both the slides and the videos. Still getting things moving forward here. But let's keep in mind that you're free to ask questions and let's move forward.
So first of all, let's start with this, which is what I like to call the greatest artifact of human civilization. Does anybody recognize what this might be? Do we have any thoughts other than random?
Yeah, very good. We've got several people that basically said internet. And in fact, there it is.
So what's great about this is that we have billions of people and devices all interconnected in one huge system. And lest you think this is a plug for... 168 or 268. This is, you know, the networking is just one of the amazing aspects of this huge system.
And the operating systems are really what ties it all together and essentially ties everybody else together, which is part of what's very cool about the internet. And of course, you're all off on the internet right now. This is all entirely virtual.
So I guess it's kind of appropriate to start a class this way. And I had a couple of people comment that this looks like a big brain. Yes, in some sense it does. It's got huge numbers of connections and interconnectivity and multiple redundancies. And so the notion of this as a brain is not entirely off base.
I think what we're going to try to do as the term goes on, we're going to try to tame some of the complexity that's hidden inside both the internet and the devices on it and see how to understand it. So, you know. Basically, if this were 168, we would probably dwell on slides like this, but this is pretty impressive. Kind of the original ARPANET couldn't handle more than 256 devices. And now we've got, you know, billions, four and a half billion devices penetrating maybe 60% of the world, which is just astounding place to come.
And, you know, some of the deadlines here, some of the dates that are particularly interesting in here is I think in the sort of the very early 90s is when the World Wide Web took off. And that was when suddenly the Internet became something that lots of people could use and turned it into what it is today. The other thing that's kind of interesting, which is in this picture as well, is this idea of the diversity of devices. There are literally, this is a graph kind of the, sometimes I like to call this color's graph, or it's Bell's law, which is the number of devices that a person has. And if you look, originally it was kind of one computer for millions of people back in the original day.
And then as things moved down, now each of you probably has hundreds of devices that are working for you. Modern cars have hundreds of processors in them. You all have cell phones and laptops and little computers inside of devices and thermostats and so on. And so this graph is kind of funny.
It's almost an inverse Moore's law graph where... the number of computers per person is increasing as they get smaller, which is kind of interesting. And there's a lot of timescales.
And so when we start talking about how to make this whole system work, we're going to have to figure out how to deal with something that's nanoseconds or femtoseconds in some cases, up to things that are seconds and tens of seconds. And. Somehow the system's got to work across those time scales.
And there's a little magic involved in that. And we're going to try to talk about this. I did see somebody say femtoseconds. No way. But a lot of the laser communications do operate very rapidly.
So we'll hold off on the femtoseconds here. But sub-nanoseconds definitely these days. All right.
Now, operating systems are really at the heart of all of this. Basically, you make... incredible advances continuously in the underlying technology.
And what happens is somehow each device is a little bit different. Every technology generation is a little different. And you got to provide somehow a consistent programming abstraction to applications, no matter how complicated the hardware is.
And you got to manage sharing of resources. Okay. So the more devices we have connected, the more resources there are to share.
And as we get closer to the end of the term, so I'm going to say the last third of the term, we're going to start talking about some of these very interesting peer-to-peer systems that are out there that basically allows us to have huge storage systems that span many devices. I did see some questions about postings of slides. We will definitely, in the future, I'll have them up earlier then. the day after lecture.
So some of the key building blocks to operating systems are really things that we're going to learn about in class. Processes, threads, concurrency, scheduling, coordination, many of these things you've learned about in the 61 series. Address spaces, protection, isolation, sharing, security, and that level of security is going to be both at the device level, and then as we build out into the network, you know, we'll talk about things like SSL, and then we'll talk about...
more interesting security models as we go. And there's going to be communication protocols. There's going to be persistent storage.
There's projects I've worked on in the past. I'll mention briefly later where it was interesting. The interesting question was how do you store information for thousands of years without it being destroyed?
We'll talk about transactions and consistency and resilience and interfaces to all these devices. So this is. a class that spans a lot of interesting topics. And so, for instance, here's something you do every day without thinking about it multiple times.
You've got your cell phone and you want to look up something on some device, a web page or maybe you're using an app. And what happens there? Well, the first thing that happens is there's a DNS request that tries to figure out what the Internet IP address is to where you're trying to go. And that goes to a bunch of DNS servers on the network, and they return information that helps now your, say, cell phone route through the Internet, which is a very interesting device in and of itself, consisting of many pieces. And that may go to a data center somewhere with a load balancer that then will pick one of several possible devices out there, which will then maybe do your search and retrieve information from a page store, put it back together into some...
page that you can use and then you get the result back and you know you do this every day and don't really think about it too much and uh once you start thinking about it gets pretty interesting like for instance how is it that those dns servers stay consistent and why is it that it's not possible to hack into them well in fact uh back in the middle 2000s people were hacking into them i'll tell you a little bit about that later um and how do you make sure that the packets get enough priority when they come into an operating system that maybe your particular query doesn't get delayed a long time. So there's some scheduling questions. So this is a pretty complex system and it's every time I spend the time to think about it I'm amazed it works. Okay it's pretty impressive and hopefully by the end of this class you'll have enough knowledge of what's going on in all parts of the operating systems and the networks that you too you know you'll be much smarter than when you started the class of course but um you'll be able to appreciate and sometimes maybe uh wonder why it is that it actually manages to work or be impressed that it works so yeah but what's an operating system okay um what does it do we could ask that question um so most likely you could you could say well from the standpoint of what it does this is like being a physicist that's maybe measuring a bunch of things you say well it's memory management It's IO management.
It does scheduling. It does communication. It does multitasking or multiprogramming. You could ask those things.
You might ask, is an operating system about the file system or about multimedia or about the windowing system or the browser? You know, back in the 90s, there was a lot of fighting between Microsoft and a bunch of other companies about does the Internet browser. constitute part of the operating system?
And, you know, depending on your point of view, that may still not be a resolved question. But anyway, it was one that has been asked. So, and also, I would ask everybody to turn off their video if they could, please, while we're talking.
So, so is this, you know, these questions only interesting to academics is a question you might ask. Okay, so hopefully not. Hopefully, it's interesting to you.
Could I ask the person just came in turn off your camera please or turn off your video because that will show up in the recording. So a definition of an operating system is no universally accepted definition is part here everything a vendor ships when you order an operating system might be a good approximation but it varies pretty widely. It might be the one program running at all times on the computer. Okay, that's the kernel. You'll learn a lot about kernels as the term goes on.
But you can see these two points of view are different. You know, nobody would disagree that the kernel is the core of the operating system. They would disagree pretty widely about, is everything that Microsoft ships with a Windows product part of the operating system? Okay, probably not.
All right. So, you know, as we try to drill down onto what an operating system is, you're going to have to keep in mind that we're going to talk about things it does and pieces that are important, but maybe you'll never fully know what an operating system is. So it's typically, among other things, a special layer of software that provides the application access to hardware resources. All right.
So it's convenient abstractions of complex hardware devices. Protected access to shared resources, okay. Security and authentication, yeah. Communication, okay. So we could look at something like this where we have some hardware, and it's the fact that many applications can simultaneously run on the hardware is something that the OS has provided for us, okay.
So, yeah, that makes sense, and you will understand exactly how this works actually in a few weeks. But maybe we could do it this way. Well, operating system.
What's the first word? Operating. Well, that comes actually from there used to be people. Like there was a switchboard operator, believe it or not.
When you made a phone call, they actually had to plug you in to the right connection and make the wires connect. Then there were computer operators, which were people that basically sat at one of these big machines for a long time and made sure it was running correctly. And then, of course, operating systems.
the operating part of it then became more about, well, we're making sure that the disk is operating correctly, or the network is operating correctly, or the graphics cards are operating correctly. All right. What about the word system?
Well, this is interesting as well. So what makes a system? So a system is something with many interrelated parts where typically the sum is much greater than the sum of its parts. And every interrelated part...
potentially interacts with others. And of course, that's an N squared level of complexity, at least. And we're going to have to come up with APIs and other clever techniques to avoid N squared complexity here, because things are complex enough as it is.
And making a system, which I showed you earlier, the internet, that's a system that has billions of components. To make it robust... and not fail is going to require an engineering mindset.
So you guys are going to have to start thinking like engineers, and we're going to give you some tools. to really think about how to make something that complicated actually work. Again, the internet is something which, you know, it's a great example of a big system that is amazing that it works. And it's actually, it doesn't always work.
I'll pull up some stories later in the term about times where it definitely didn't work. My favorite being one time where there was a single optical fiber that divided the network into two pieces and it went through this tunnel in the middle of the country, the US, and a truck went in and blew up. and it melted this fiber and it actually temporarily partitioned the network.
So there are times when it just doesn't work properly. Okay. So systems programming is an important part of this class and you're going to do a lot of it. Okay. You're going to learn how to take a system like this and figure out exactly how to make it work.
And that's exciting. Okay. You're going to get some of the tools.
You're going to learn about Git. You're going to learn about how to work in groups. You're going to learn about...
testing and all of these things that help to make a complex system actually manageable and hopefully eventually workable. Okay, so part of making things work are interfaces. So here's a 61C view maybe of things, the hardware software interface. So you have hardware, that's these bricks, and you got software, which might be a program.
And 61C, which hopefully will start coming back to you very rapidly. You had a processor and you had memory, which had the OS in it maybe. You had registers in the processor, and those registers pointed at parts of memory.
And that allowed this program to run. Maybe you had caches. We'll learn about caches again and remember, mostly remind you how they work, which helped to make the slow memory look fast.
The way I like to think about... system with caches is you want to make it as fast as the smallest item like the registers and as large as the largest item like the memory or disk and the way you do that is with caches. Okay and of course there's page tables and TLBs which will help us out in virtual memory and there's storage disk drives etc there's all sorts of devices like networks and displays and inputs And so making all of this tie together is something you started down the path with 61C.
Hopefully you remember that. And then, of course, there's interesting things like buses that tie it all together. Okay.
And I, you know, 61C doesn't quite get into that level of detail. And we're not going to do that too much. I might suggest 152 and 151, some of those interesting classes. If you really want to talk about the, maybe 150, if you want to talk about the buses and so on.
But then of course there's an instruction set architecture which you did talk about and that abstracts away a lot of what's going on in the processor so that people running programs and compilers that are compiling programs have something common to use. Okay and so what you learned in 61c was machine structures and you also learned C which you're going to get to exploit a lot. So I know the notion that in 61c you learn C is Maybe shared with a little bit of skepticism by people, but you're going to get to learn it a lot more in this class. So the OS abstracts the hardware details from the application.
So not just the instruction set architecture is going to matter anymore. So that abstracts away the computation elements of the processor. But we're going to learn how to turn a bunch of storage devices like disks and USB keys.
cloud storage and turn it into a single abstraction, like say a file system, so that a user can use that easily without having to worry about where the bits are stored. Okay. And so that's where we go with this class is we're going to learn not just about the abstractions from hardware for 61C and processor, but abstractions for other devices as well.
Okay. So what is an operating system? So let's go through some things it does again.
Let's try to maybe get an idea operationally. So one thing that I've started to talk about here is the fact that the operating system is an illusionist in some sense. All right, it's going to provide clean, easy to use abstractions of physical resources.
And it's going to do so in a way that allow you to at least temporarily think that you've got infinite memory, you have a machine entirely dedicated to you or a processor, that there are higher level objects like files and users and messages, even though as you probably already know, but will know very well by the end of the term, there aren't files, files are an abstraction of a bunch of individual blocks on a disk that somehow are put together with inodes to give you a file. So the operating system is busy providing an illusion of a much more usable machine. so that when you program it, you have a much easier time of it. And you don't have to worry so much about whether it's on disk or on a USB key or in cloud storage. And we're going to learn also about abstractions of users and messages.
And we're going to talk about virtualization and how to take the limitations of a system and hide them in a way that makes it easy to program. So for instance... So virtualizing the machine. So here's our 61C machine, which has a processor.
It's got memory. It's got IO with maybe storage and networks. And on top of it, we're going to put this operating system thing, which we're learning about as we speak. And that operating system, instead of giving us a processor with limitations the processor has, it's got a certain set of registers, it's got certain floating point operations, it has certain exceptions that are caused and so on.
We're going to give an abstraction of something really clean called threads. We're going to have address spaces. For instance, we're going to learn about, rather than a bunch of memory bytes that are in DRAM, and scattered about, we're going to provide a nice, clean address space abstraction that will give us the ability to treat the memory as if it's entirely ours, even when there's multiple programs running.
Again, I just talked about files. Rather than a bunch of individual blocks, we're going to have files. And rather than networks, which are a bunch of individual Ethernet cards, let's say, that are connected point to point between here and Beijing, we're going to have sockets and routing under the covers.
Okay, so that's a pretty clean abstraction, which of course ultimately allows me to teach you guys, spread all over the globe as you are. Okay, on top of this, these threads, address spaces, files, and sockets are going to be the process abstraction. And that process abstraction is going to give us an execution environment with restricted rights provided by the operating system. And that process abstraction is going to be a nice virtual machine that your program can run in that's abstracted away from all of these physical details.
Okay. And so on top of that, you could have your program. So the one thing that you guys get to do a lot more of than you've done so far in your career is you get to actually do user-level programs running on top of a Unix environment. Okay. And so.
You're going to have compiled programs that you have produced that are going to run on top of your process abstraction. And in order to give you a clean environment into the process abstraction, there'll be system libraries. So there's even system something, the C library, the security libraries, many of the libraries abstract even further and give you nice clean abstractions that maybe allow you to do SSL very easily or so on. Okay. There is an interesting question in the chat, which I'm going to point out.
Some people are asking about closed captioning. Some classes, like last term, we even had closed captioning, but that's when we need it and we actually have a live captioner in that case. Unfortunately, we don't. But what I will do when I put the videos up is they will get automatically closed captioned by YouTube when I put them on there. And so that'll be something, but they won't be live.
Sorry about that. So this is our virtualized machine view. And the application machine is the process abstraction provided by the OS and, some people might argue, including the system libraries.
And each running program runs in its own process. And the process gives you a very nice interface, nicer than hardware. Now, the question here on the chat here is, is the hypervisor or Docker daemon a part of the process? process acting on as the top layer of the VM.
So we will talk a little bit later in the term about Docker. Docker is a way of wrapping up multiple different little environments and potentially running them inside the process abstraction. It's not as isolated as say a full virtual machine, but we'll talk more about that in detail.
Let's stick with process abstractions for now. The process abstraction, as I'll show you in a second, you can have multiple processes all running at the same time, and they're each given isolation from each other. So that's what we're going to start with for this first lecture.
So the system, ISA by the way stands for instruction set architecture, that was the question. So the system libraries, what does a system programmer think of? Well the system libraries are linked into your program, which is then run by a compiler and turned into bits that will run in the process. You're going to get very good at this as well, as you're going to learn how to compile programs, link them with libraries, and then execute them in a process environment. And you'll learn how to invoke the compiler to do that.
So this is the programmer's view. So what's in a process? So remember, the process here is an environment, right, that gives you threads, address spaces, files, sockets.
So a process, as I said, has an address space, which is a chunk of protected memory. It has one or more threads in it, one or more threads of control executing in that address space. And...
the system state associated with open files and sockets and so on. And so this is a completely isolated environment. We're going to dive into processes very quickly in this class.
And you're going to learn how we can have a protected address space and multiple threads running in an environment that's protected from other processes, even though, for instance, maybe there's only one core running. We're going to give the illusion that there's multiple cores running with multiple processes at the same time. So you've all done this. Here's an example on, say, a Mac where you look at the process monitor or the task manager or you do a PSAUX on Linux box.
And what you see here, which is perhaps surprising if you haven't really thought about it, is that there are many processes running all the time on your typical laptops. Okay, so many things go on simultaneously. 50 or 100 of them.
Mostly they're sleeping, but they're there to wake up and do some execution at some point. Now the question of why are the middle layers of abstraction necessary? So part of the reason that we have many layers of abstraction is that if you tried to squash all the layers down, which is sometimes done in very specialized environments, you end up with an undebuggable mess.
Okay, and so multiple abstractions assuming they don't make things too slow Are a crucial aspect to making things actually work properly Okay, and so you'll see even modern operating systems still have several abstraction layers Okay, and you'll appreciate them. I think as we go forward because it's much easier to actually have an operating system that has a device driver talking to the disk and then you have a file system that provides files and then you have a process abstraction which protects those files and exports them to programming. And yes, somebody brought up the imagine programming in ones and zeros. I can say that I've done that.
And it's not pleasant. But anyway, moving on here. So here's the operating system's view of the world when there are multiple processes. So each process gets its own set of threads and address spaces and files and sockets.
Okay, and they might run a program with its own linked libraries, okay? But what's interesting about this point of view is these processes are actually protected from each other Okay, so the operating system translates from the hardware interface down below to the application interface and each program gets its own process Which is a protected? Environment all right and so in addition to illusionist we're going to talk about Another thing that operating systems do, which is referee, which is manage the protection, isolation, and sharing of resources.
And this is going to become particularly important when we talk about global scale systems. You could imagine we talk about storage that spans the globe with many individual operating systems running at the same time, each of which could be corrupted in one way or another. You kind of get to the interesting question of, well, how do you protect anything? And this is where the referee point comes into play. And so...
Here, I'm going to show you, we're going to now be more consistent with our coloring for what's going forward. But here we have compiled program number one and number two. Each of them are linked with system libraries. You're going to learn about the C library very shortly, like I said. And they are running independent of each other.
And however, in this simple example, there's only one processor. Okay, so that one processor. and one core, by the way, before somebody asks, we're going to say one processor, one core.
And how can these two things appear to be running at the same time? Well, we start out with one of them running. So the brown one's running.
It's using the processor registers. It's got a process descriptor and thread descriptor and memory. You'll learn about those as well.
And it's busy getting CPU time. The green process is not running, but it is protected. And so now, how do we get the illusion that there's more than one processor or that each process has its own processor?
Well, each process has its own process descriptor in memory, and then the operating system has to have some protected memory as well. And what we're going to do periodically is we're going to switch from brown to green and vice versa. Okay, so here's the example of going from brown to green.
So the brown device has this process descriptor here. The green one has the other, the green one. And what we do is we go through a process switch where the registers are stored through the OS into their own process descriptor block. And then the green ones are reloaded. And what happens is, voila.
the registers are now pointing at the green memory and the green one picks up from exactly where it left off. Okay. And then a little bit later, a timer is going to go off and we're going to switch back the other way. And if we do this frequently enough, you get the illusion that multiple processes are running at the same time.
And we're going to talk about this, how this works in detail. So I can very confidently say that in a few weeks, you will have a very good idea of how this works. So, but At the high level, it's very simple. We're just switching the processor back and forth between brown and green.
And as a result, we get the illusion that they're both running. And notice that what do I mean by the illusion? Well, the process one can pretend like it's got 100% of the processor.
And process two can pretend it's got 100% of the processor. And things just work out. OK, and that's up to the operating system.
Now, the question that's interesting here, and does a program become a process when loaded into memory? A program becomes a process. That's a very good question for next week. But when a program becomes a process, when the binary has been loaded into memory and into the proper OS structure, so it has to have a process structure allocated for it, and it has to be put into the scheduler queue and so on. Once that's happened, now that process is an instantiation of a running program.
So going a little further to that. question that was there. Both brown and green could actually be the same program running in different instances with different states.
So we could have one program, two processes, each of them doing something different. And this is typically what would happen if you were logged into a shared machine and you were both say editing with Emacs or VI, each of you would have your own state. Okay, so and then the interesting thing about shared data we'll get to in a little bit next week probably.
But yes, so you guys are way ahead of me. So that's good. So now the question about, I will say one answer this question here about what does it mean when a process is some percent of the CPU, that literally means what it says. If process one has 90% of the CPU and process two has 10, it means that if you were to look from 10,000 feet you would look down and you'd see that process one gets the CPU 90% of the time and process two gets a 10% of the time. Okay.
And mostly what you're going to see is that there might be one thing that's getting most of the CPU and the rest of them are getting very little of it. And that's because they're mostly sleeping or waiting on IO typically. But if you look carefully and you you add everything up, you'll actually get a hundred percent.
Okay. But that oftentimes if something's mostly idle, most of that time comes up as the idle process, which we'll talk more about too. Okay, so let's talk briefly about protection.
So here we have brown and green, but I said they were protected from each other. So what happens if process two reaches up and tries to access brown's memory, or tries to access the operating system, or tries to access storage, which is owned by some other user? What happens is protection kicks in the operating system and voila, we basically give that process the boot and typically cause a segmentation fault, dump core, and the green process is stopped.
Now, the question about more than 100% is an interesting one. It really depends on how the statistics are reported. If you have multiple cores, you'd have to say four cores.
In one view of the world, you could have up to 400% execution. In another, you could say only if you use all four cores, you get 100%. So you have to be very careful about what the reporting statistics are, because I've seen them both ways. Okay, but if you have more than 100%, then you definitely have it reporting multiple cores, or each core is 100%.
Okay, so does one CPU equal one core? I'm going to say yes for now, and just know that that's not the whole story. We'll go a little further for now, but for now, today, you can certainly think of one CPU equal one core for this lecture. Absolutely.
One CPU chip often has many cores, and so we're not going to go there today, but we're going to go there. So this protection idea is really the OS synthesizes a protection boundary, which protects the processes running on top of the virtualization from the hardware and prevents those processes from doing things that we've deemed not correct, that are not part of the protection. And the virtual memory, which we're going to talk about... as we go is exactly what I just said here. So I didn't talk about this in terms of virtual memory, but one of the reasons that the green process isn't able to reach out and touch the brown memory is that virtual memory prevents it.
But this reaching out to memory you're not supposed to have access to can be shown in reaching out past the boundaries of what the operating system has mapped for you in virtual memory as well. Think of today's lecture as giving you some of the ideas at the high level, which we're going to drill down to in a couple of lectures. So this protection boundary is, again, part of the virtual machine, okay?
Abstraction. Somehow we've got these networks which have little packets with MTUs that are 200 bytes and what have you. We've got storage, which is a bunch of blocks. We've got, you know, controllers, which do a bunch of complicated stuff. You as a programmer don't want to think about the network.
individual hardware because if you had to do that you'd be you know you wouldn't be getting anything done and so part of what the OS does is it really puts these protection boundaries in gives you a clean virtualization precisely so you can program without thinking about those things and you can program without worrying about somebody else trying to hack in as well so that's the idea there's an interesting question on the chat here about whether the Java virtual machine would be an OS and yes There are points of view in which the Java virtual machine could be considered an OS. So let's save that question for another day, but bring it back if it looks like we're going somewhere where that's appropriate. So the OS isolates processes from each other.
It isolates itself from other processes. And even though they're all running on the same hardware. So that's an interesting challenge, which we're going to tell you how it works.
So finally, the operating system has a bunch of glue that it provides, which are common services. So you may not have thought it this way, but if you have a good operating system, it's going to give you a file system. So you're going to get a storage abstraction or it's going to give you windows that properly take in mouse clicks and so on.
Or it's going to give you a networking system that can talk from Berkeley to Beijing and back without worrying about packets. OK, and so. These common services are actually typically linked in with libraries, and those libraries are things that you come to depend on when you're writing a program. So really, an operating system, if you were to look at its functionality, referee, illusionist, glue, all of these things are part of what an operating system might be considered doing. What gets interesting when you have non-mainstream operating systems, like if I don't run out of time, I'll briefly talk about the Martian rover, for instance.
You might try having stripped down versions, not as much functionality to try to run on simpler hardware or in a less malicious environment where there might not be somebody hacking in. And so many times people build specialized operating systems, which perhaps don't have all the protection internally, or maybe they don't have all the storage services that you might see here, etc. And that's... Doesn't make it any less an operating system. It makes it a more directed operating system at a particular task.
So finally, the OS, some of the basics are I-O. And clearly, I've just said that we're providing the ability for storage and networks to have a nice clean abstraction into the hardware that we can deal with. And that's the common services. So There was a question here about flipping transistors and heat.
I tell you what, I promise as a computer architect to talk about that in a few lectures for you, if that's interesting. Is there a smallest OS? Well, there was something that David Culler put together in the early 2000s called TinyOS, which is pretty small. Okay, so finally the OS maybe gives you some look and feel. So maybe you have display services.
There is an interesting point back to what I talked about earlier in the lecture here. Is windowing part of the operating system? Is the browser part of the operating system? Well, perhaps.
Depends on what operating system. So for instance, Microsoft Windows. went through a phase, the Windows NT initially had, was a microkernel type operating system, and the windowing system was outside of the kernel. And then they decided they weren't getting enough performance.
And so they went the opposite direction and put the windowing entirely inside of the kernel, which is almost like a reactionary response. And so you could have windowing both in and out of the kernel. And the distinctions there have to do with protection, security, durability, reliability, some of those questions come up and hopefully you'll have enough to judge where you think it belongs as we get further into the lecture or further into the class.
And then finally we got to deal with power management and some of these things which only really show up on portable devices but these are all potentially managed by the OS. So what's an operating system? Referee, illusionist, glue? many different possibilities. So why should you take 61C?
Well, other than being one of the best classes in the department, if I do say so myself, some of you will likely, I said 61C, I meant 162, my apologies. Boy, I'm slipping up here tonight. But some of you are actually going to...
Design and build operating systems. So by the way, just to be clear, I was saying that CS162 is one of the best classes. But you shouldn't quote me on that. I'll get in trouble.
But some of you may actually design and build operating systems in the future. And it'd be very useful for you to understand them. Okay.
Many of you will create systems that utilize core concepts and operating systems. So this is more of you. It doesn't matter whether you build software or hardware or you start a company or a startup.
The concepts you lose that you basically use in 162 are ones that are going to go across very easily to many of these different future tasks that you're going to do. And so you're going to learn about scheduling. And, well, you could schedule in the hardware.
If you're designing processors, you can schedule in the lower levels of the OS. If you're building a core OS, you could schedule. In a big cloud system if you're building cloud apps and so the ideas that we learn here actually Go across to many different places and we'll even talk about some cloud scheduling as we get a little later in the term All of you are going to build apps. I guarantee it as you go forward Okay, and you're going to use utilize the operating system And so the more you understand about what's going on the more likely you are to a not do something that was not a smart thing to do.
Hopefully you'll learn about locking, you'll learn about concurrency, you'll learn enough about the right way to design some of these systems that you're going to write amazing bug-free software as opposed to almost amazing, very buggy software. Okay. So who am I? So my name is John Kubitowicz.
Most people call me Professor Kubi, maybe because they can't pronounce my last name. But I have background in hardware design. So there's a chip I designed for my PhD work, which was one of the first shared memory multiprocessors that also did message passing called Alewife.
I have backgrounds in operating systems. I worked for Project Athena at MIT as an OS developer, did device drivers and network file systems, worked on clustered high availability systems. We had a project for a while in the ParLab called Tessellation.
which was a new operating system we were developing for multi-core processors. I did a lot of work in peer-to-peer systems, so the Ocean Store project, this was our logo here of the scuba diving monkey, was addressing the idea of storing data for thousands of years and we were pretty much one of the first cloud storage projects before anybody talked about the cloud back in the early 2000s. And so some of the concepts I talk about at the end of the term will come from some of those ideas.
I also do some quantum computing, and perhaps you could get me to talk about that at some point, but it's a little off topic for this class. And most recently, I've been working in the Internet of Things. the swarm.
Specifically I have a project called the global data plane which is looking at hardened data containers. We like to use the analogy of these shipping containers that everybody sees down at the Port of Oakland where these shipping containers are cryptographically hardened containers of data that can be moved around to the edge devices and back into the back into cloud and are ideal for edge computing and so we'll talk some about some of these ideas as well. And if any of you are interested in doing research in that, that's certainly something you could talk to me about.
All right. And I will say that quantum computing is a real thing, becoming more real as we go. It's got to be real because Google and IBM talk about it all the time now. So that's a little bit of a joke.
But we have a great set of TAs this term. And Neil Kulkarni and Akshat Gokhale are... co-head TAs, and we have a set of really good TAs, and so I'm very excited about our staff, and I will tell you a little bit about where we're at in terms of scheduling sections.
We haven't, the sections are still TBA, and I'll say a little bit more about why that is in a second. Okay, so let's talk a little bit about enrollment. The class has a limit of 428. I just raised it and it's not going to go any higher.
So probably won't make the class any larger. There's one circumstance where that might happen, but I think it's unlikely at this point. This is an early, so I will say something here.
So running a class virtually in the middle of a pandemic, especially something like CS162 is a serious challenge. And so what we're doing is you're going to have a pretty good, I would say an excellent ratio of students to TAs this term. And and that's to make sure that things all be smoothly running.
OK. And so probably won't make the class any larger. The other thing to keep in mind is this is an early drop class.
OK, so September 4th, which is a week from Friday. is the drop deadline. And what an early drop class means is it's really hard to drop afterwards.
Okay, so the next two weeks, you need to make sure that you want to be in the class. Okay, because if you are still in the class and you get past that early drop deadline, you either have to burn your one special drop late. token that you get as a student or there's some appeals process that doesn't always work.
So the early drop deadline is really there to make sure that when you guys start working in groups, it's going to be stable. Okay, we put, we instituted that because what would happen is people would form their groups and students who weren't entirely serious about the class ended up dropping out on their project partners and that got to be a problem. So what we need to do in the next two weeks is everybody needs to make sure they want to be in the class. And if you don't, you should drop early so that people could get in because we currently have a wait list that was 75 or so in the last I checked.
The other thing which I'm going to say more about in a moment, but we're very serious about requiring cameras, okay, for discussion sessions, for design reviews. and even for office hours, okay? And we're going to certainly use them for exams.
So if you don't have a camera yet, you need to find one. The only place in this class where you're not going to want to turn on your camera is lecture because having, we currently have 328 people on the chat there, and so that would be bad. I think with the wi-fi issues people are asking about, let's just do your best, okay?
Zoom tries to adjust a little bit. And we'll deal with problems on a case-by-case basis. But I'm going to tell you more about this in a moment. But really, having a class like this all virtual is very hard unless people interact a little more normally. And so that's really requiring people to be able to see you.
Okay? If you're on the wait list, like I said earlier, we kind of maxed out sections in TA support. So if people drop.
they're gonna we're gonna automatically move people from the the waitlist into the class so here's the thing you should devs absolutely not do and if you have friends who are, you know, we're just on the class and are thinking they're not going to take the class, make sure that they either get themselves off the wait list or they do all the work in the class. Because as I'm going to mention a little bit, if you're still on the wait list and a spot opens up, we will enroll you in the class and you'll be stuck, of course, with an amazing class, as we mentioned earlier. If you're not keeping up, that could be a problem if you, because we have occasionally had people discover weeks into the class that they were enrolled and, you know, couldn't get out of it. So don't be one of those people.
Now, the question about discussion sessions, I'll say a little bit more about them in a moment. Okay. But how do we deal with 162 in the age of COVID-19? Well, if you look at this particular wordplay here, we've got collaboration in the middle, we've got to remember people, and we've got to figure out how to combine all of you together in your groups and produce something successful. So this is challenging.
And I know this is not the term you thought you were getting this fall when you, you know, when you thought about coming to Berkeley, and I apologize. But most of you, I think, experienced the end of last... semester, unfortunately. But collaboration is going to be key.
Okay, so things are considerably different, I would say this term, even than they were last term, because we're starting out fully remotely. So you don't even get to see anybody in person, probably. Maybe some of you will get to see each other, but I would bet that the bulk of you don't. Most important thing is people, and then interaction and collaboration.
So I put up something here to see all remember. You know, I fondly remember coffee houses. This is what they kind of look like. You know, you sit with people and you drink beverages of choice. I'm going to say coffee to keep from getting in trouble.
And you discuss things. Okay, so this is how groups ought to work. Okay. And the question is, how do we do this when people are all remote?
And so first of all, we're going to have to use, it's going to work. It's going to require work. Okay, I hate to say this, but The way we make this turn out well is we've got to work at our interactions.
Because, as you well know, if you don't look at anybody with cameras on or whatever, and you just exchange email, that can go south very quickly, even when you didn't intend to imply something, and everybody gets their feelings hurt, and things are just not working out well. So we've got to figure out how to bring everybody along with us so we don't lose anybody. And if you notice here, by the way, these people are holding hands. That's virtual, so we're not suggesting that you don't socially distance when you're bringing people along.
But the camera is a part of this. Okay, so this is, call this an experiment, but cameras are going to be an essential component. You've got to have a camera and plan to turn it on.
And if you have issues with spectrum, let's see if we can figure out ways of maybe lowering the bandwidth a little bit. But you certainly need it for exams. Okay, so if you don't have a camera, you got to make sure you got enough spectrum and a camera for the exams.
And you're going to need it for discussion sessions, design reviews, and office hours, possibly even. That's going to depend on whoever's running the office hours. I'll get to section this week in a moment. But yes, we do have section this week. But the thing about cameras is it gives the ability to at least.
approximate what we used to be able to do when we sat physically in person. In fact, I may even, in fact not even me, we are probably going to give extra credit points for screenshots of you and your group meeting on a regular basis drinking a beverage of choice and talking to each other. Okay, so this is the kind of thing that needs to be strongly encouraged.
Even before we had a pandemic, I had groups that Somehow, despite the fact that they could meet, never met the whole term. OK, and this was got bad. And by the end of the term, the group, all of the members were upset with each other. They, you know, the project failed and they all got bad grades. And this was just a bad scenario.
And it didn't have to happen that way because they should have been meeting. They should have been looking at each other while they were talking. and it didn't happen. So this is our experiment. Okay, and so cameras are a tool, not of the man, they are a tool of collaboration.
Okay. So we want to bring back personal interaction, even though we're on either side of fences. Humans are really, even computer scientists are not good at text-only interaction. So we are going to require attendance. We're going to take attendance at discussion sessions and design reviews with the camera turned on.
So hopefully that's clear. Any other questions on the camera? You can, why don't you type your question.
And people turn off their mic if they're not asking a question. Actually, type your questions too. All right. So infrastructure, well, it's only infrastructure. You can't come see us, but we have a website, which you've probably all gone to, cs162.exe.berkeley.edu.
That's going to be your home. for a lot of information related to the course schedule. We also have Piazza, so hopefully you all have logged into Piazza already. Assume that Piazza is the primary place where you're going to get your information.
I'm also going to be posting the slides early, as have been asked several times, on the website, on the class schedule, and when the videos are ready, they'll be posted on the class schedule as well. So you'll be able to get everything related to the schedule on the website and then Piazza is kind of everything else. Okay.
The textbook is this, uh, principles and practices of operating systems. Uh, it's a very good book. Um, the suggested readings are actually in the schedule. And so you try to keep up with the material. Um, you can get a red version, um, on text of what I talk about.
And I think those two together help a lot. There are also some optional things you could look at. So there's, uh, I know David Culler really liked this operating system three easy pieces book, the Linux kernel development book.
Some of these are interesting maybe to look at as a supplement. One thing that you may not have known is if you log in with your Berkeley credentials to the network, which I think you need to use a virtual VPN to do that, but you can actually get access to all of the O'Reilly animal books. over the network as well.
That's something that Berkeley's negotiated with the digital library, which is pretty cool. And then there's online stuff. Okay, so if you look at the course website, we've got appendices of books.
We've got sample problems. We've got things in networking databases, software engineering, security, all that stuff's up there. Old exams.
So the first textbook is definitely considered a required book. You should try to get a copy even if it's only an e-book. There's also some research papers that are on the resources page that I put up there, and we'll actually be talking about some research as we get later in the term. So use that as a good resource.
So the syllabus, well, we're going to start talking about how to navigate as a system programmer. We're going to talk about processes, I.O., networks, virtual machines. Concurrency is going to be a big part of the early parts of this class. So how do the threads work?
How does scheduling lock, deadlock? scalability, fairness, how does that all work? We'll talk about where address spaces come from and how to make it work. So we'll talk about virtual memory and how to take the mechanisms and synthesize them into interesting security policies. So virtual memory, address translation, protection, sharing.
We'll talk about how file systems work. So we talk about device drivers and file objects and storage and block stores and naming and caching and how to get performance and all of those interesting things about file systems, which you probably haven't thought about. And in the last sort of couple weeks of the class, we'll even talk about how to get the file system abstraction to span the globe in the cloud storage system.
So that'll be interesting. We'll talk, like I said, about distributed systems protocols, RPC, NFS DHTs. We'll talk about core.
We'll talk about tapestry and some of those other things. And. We'll also talk about reliability and security to some pretty big extent.
There's a question in the chat about cloud systems and why they haven't really taken over as operating systems. And I think maybe they have more than you might think. I think the cloud has really become part of our day-to-day lives and things that people call the cloud operating system, maybe where they put capital T, C, O, S or something may not have taken over.
But a lot of other... mechanisms have been synthesized together in a way that you haven't thought about. So hopefully by the end of the term, you'll have enough knowledge to evaluate that question for yourself.
you know, what is up with the cloud and is it really a monolithic thing or is it a bunch of mechanisms and where is that at? Okay. So we learned by doing in this class. So there's a set of homeworks and each of them is kind of one or two weeks long.
There's one that you got to get going right away, which is you need to get going on homework zero. So this is one of the things that we do in the very first week. It's already been released, I believe, and you should get moving on it. And it's basically learning how to use the systems.
And there's also a Project Zero, which is done individually, and you should get working on there too. So this class is as much about knowledge as it is about actually doing things. I should have said it the other way. It's as much about doing things as it is about knowledge.
So you're going to do build real systems, okay? And... And you're going to learn some important tools as you do that and they're either going to be done individually or they're going to be done in groups.
Okay. There was a question about Kafka and Cassandra. Probably we'll get some concepts from them a little bit later. Okay. So a big thing to learn about from this slide is get going on Homework Zero and Project Zero will probably get posted soon.
And both of those are things to do on your own without your group. So group projects have four members, never five or never three, okay? It's four.
Three is a very serious justification requirement. You must work in groups in the real world and learn how to do it here. And all of your group members have to be in the same section with the same TA, okay?
And so that's why the sections that you attend, and you are going to attend sections in the next couple of weeks, are just any section you want because we don't have your groups yet. And once we have your groups, then we will assign you to sections and go from there and you should attend the same section. And that's when the requirements for attending section will kick in. And we do have a survey out on time zones and so on to try to get an idea where the best place to put some of these sections are.
So communication and cooperation are going to be essential. Regular meetings with camera turned on is going to be important. You're going to do design docs and be in design meetings with your TA.
And I will tell you, yes, you can use Slack and Messenger or whatever your favorite communication is. But if that's the only thing you do, it's not going to be great. OK, you've got to have your camera.
You've got to get together and see each other. The group, your groups are actually going to have to be. formed by I think the third week of classes it's in the schedule take a look but when we get into groups I'm going to actually have a lecture half lecture where I talk a bit about mechanisms for groups as well okay and sort of ways that you can cope with the typical problems that groups have and sort of what are some good good tools there to give you a little idea But short answer is you've got to decide groups very shortly.
And we do that typically after the early drop date because at that point, in theory, people are stably going to be in the class. And we're going to have some mechanisms to help you form groups. There's going to be a piazza looking for a group kind of thread. We may even have some Zoom rooms set up for people to sort of, you know, I don't know, interview your.
group members or talk to them. We have a couple of different things we've been thinking of just to try to get your groups together. But keep in mind, you want to have four members in your group, okay? Not five, and three is probably only under serious justification, okay?
And you're going to be communicating with your TA, who's like a supervisor in the real world. So this group thread here is very much like... what you're going to run into when you finally exit Berkeley and confront the real world. So how do you get started?
Well, there's going to be a survey out. Okay. So the, um, the, the question in the chat about, uh, TBD, yes.
So the group, uh, you, uh, we're assuming that, uh, many of you might not have group members yet. And it's also the case that the, um, Final discussion session times haven't been decided, only for the next couple of weeks until groups are formed. There's going to be a time zone survey or a survey out. You probably have already seen it. I think it was released on Piazza.
But you need to. Fill that out. Let me know where everybody is. I want to know if you're in Asia or if you're in Europe or you're in New York or whatever. Get going on Homework Zero.
Project Zero is not quite out yet, but it will be very soon. But Homework Zero kind of gets you going on things like getting your GitHub account and registration and getting your virtual machine set up. get familiar with the 162 tools and so on and how to submit to the auto grader so project so homework zero is up and it's something to get going on right away and we will announce as soon as project zero is up it's going to be out soon um sections on friday attend any section you want uh that we will post the zoom links if they're not already posted um very shortly and uh you'll get your permanent sections after we have our group set up okay so you're gonna to prepare for this class, you're going to have to be very comfortable with programming and debugging C. You're going to want to learn about pointers and memory management and GDB and much more sophisticated and large code base than 61C.
And so we actually have a review session on Thursday, the 3rd of September, to learn and review quickly about C and C++ concepts. And just Stay tuned, we're going to get that out and consider going just to give you a refresher. The resources page has some things to look at.
There's some ebooks on get and see. There's a programming reference that was put together by some TAs a couple of terms ago. And so first two sections are also about programming and debugging. Okay, all right.
The tentative breakdown for grading is there's three midterms, there's no final. The midterms are going to be Zoom proctored and camera is going to be required. Just so you know, please figure that as part of the class.
And so get yourself a camera. So that's about 36% projects, 18% homework, 10% participation. And let's see. So, yes, Zoom proctoring.
projects. I've already talked a lot about homeworks you've heard about a little bit. As far as the midterms are concerned, we are going to set times after we know more about where people are. Okay. Midterms are, I have, we haven't entirely decided, but they're either going to be two or three hours long each.
Okay. So the other thing I want to talk about here is personal integrity, which is there is an academic honor code. which as a member of the UC Berkeley community, I act with honesty, integrity, and respect for others. You guys can take a look at it.
I strongly suggest you look at it. This class is very heavily collaborative between you and your group, but it should not be across groups or across other people on homeworks. So things like explaining a concept to somebody in another group is okay. Discussing algorithms or maybe testing strategies might be okay. Discussing debugging approaches or searching online for generic algorithms, not for answers.
These are all okay. These are not things where you're getting specific answers to your labs and homeworks. Sharing code or test cases with another group, not okay. Copying or reading another group's code, not okay.
Copying or reading online code or test cases from previous years, not okay. Helping somebody in another group to debug their code, not okay. So sitting down for a long session of debugging to help somebody without maybe thinking you're not copying code in, I'll tell you, a long debug session has a tendency to cause the code to become looking like your own code.
So that's not okay. And we actually compare project submissions, and we catch things like this okay we actually caught a case once where somebody sat down and debugged with another group and helped him out and didn't do any direct copying or at least they claimed not but when it was done the code looked so close that the automatic tools caught it so don't do that and the other thing not to do is don't put a friend in a bad position by demanding that they give you their answers for homework okay we had several cases we've had several cases like that recently where One person was having trouble with homework and they kind of guilted a partner or a friend into giving them an answer. And that gets both of them in trouble. So don't just don't do that.
Do your own work. And by the way, to help this, we're trying for the first time during the term to not have. a curve in this class. We're going to actually do an uncurved version of this.
We haven't put up the thresholds yet, but we'll see how that works. But please just don't put your friends in bad positions by making them give you code because they get in trouble as well and it's just not worth it. And you don't learn what you could learn by actually doing the work.
Okay. It's kind of what's the point of being in the class in the first place. So, all right.
The goal of the lecture is interaction, and so lots of questions. All right, we already had a bunch of questions today. That's great.
I'm hoping that this continues, okay? You know, sometimes it may end up that we don't quite get through the topics I was hoping, but it's much better to have interesting questions. And what I can do in a virtual term like this is I can even have some supplemental extra, you know, 30 minutes of lecture I can post or something if we don't quite get through this stuff I thought we would.
So let's give this a try and see if we can make this virtual term as good or better than it would be under normal circumstances. All right. And again, if you have more questions about logistics, you know, Piazza, the class website, those are your two best places to look for information.
So let's finish up. here in the last 10 minutes or so and ask a little bit more about what makes operating systems exciting and challenging. Okay, this is what makes operating systems exciting. Okay, the world is a huge distributed system.
We showed you what people were calling the brain view earlier, kind of like that, of the network. But the thing that's interesting about it is all the devices on there, from massive clusters at one end that span the globe, down to little MEMS devices and IoT devices and everything in between. Okay, this is... You know, modern cars, for instance, have hundreds of processors in them. Refrigerators have processors and web browsers.
I mean, we've got huge cloud services. We've got cell phones, little devices everywhere. All of this together is one huge system. This is exciting.
I mean, why does this work in the first case and what's its potential? Okay. So, you know, this is why I think operating systems are so exciting because it's what makes this all work.
Without them. there would be chaos and things just wouldn't work. So of course, you've all heard, you wouldn't be at Berkeley if you hadn't, many times about Moore's law. So the thing about Moore's law, which I like, and I always want to mention, is over the, Moore's law basically says that, you know, for instance, you get twice the transistors every 1.5 years or so, for many years, although that's starting to disappear on us now. But what you may not know, so that's an...
an exponential curve, or a straight line and a log linear curve. What you may not know is Gordon Moore was actually asked at a conference once what he thought was going to happen. And a log linear graph on the fly at the conference, he put down a couple of points, drew a straight line and said, well, this is what's going to happen far into the future. Now, normally, that would be ridiculous and laughable, except he was right, which was pretty amazing. Okay.
So what's the thing about Moore's law? The thing about Moore's law is it allows you to make zillions of interesting devices because there's so many transistors that you can shove into a little bit of a device. Of course, the downside, which happened back in the early 2000s, was that putting these transistors increasingly on chip kind of ran into problems with capacitance and power such that you weren't able to make an individual processor as fast.
It used to be that you could... you know, wait a few years and get twice the performance of a machine that you were currently working with, somewhere around the 2000s that stopped, and suddenly, what did you do? Well, suddenly people had to make multi-core processors and lots of parallelism. And so, you know, from an operating system standpoint, this is par for the course, because, you know, I already showed you a huge system with billions and billions of devices. And so, yeah, so the fact that chips have multiple cores on them is cool.
It's, you know, it's enabling of lots of stuff, but it's just kind of that's the way it is. And it's interesting about how we get around that complexity. Okay.
So around the 2000s, we suddenly had multi-core. The power density thing, I think, is a funny way to look at this. If in 2000, if instead of basically trying to keep making the processors grow as fast in performance as they were, if you had done that, what would happen is we would have chips. that had the power density of a rocket nozzle. And you can imagine putting a laptop like that on your lap might be a little uncomfortable.
So power density, capacitance, a lot of things is what kind of led people to suddenly make multicore instead of making things faster. But they did that, okay? So by the mid-2000s, we had many... cores on a chip.
Okay. And so parallelism is exploited at lots of levels. All right. And somebody pointed out the stock of Intel and AMD went up hugely.
That's true. But that was because they were delivering something that everybody needed, which was lots of processors on a chip. All right.
And the problem, of course, is, as you're well aware, Moore's law is ending, and it's not officially, well. It's officially over in the original growth, but people are still shoving a few more transistors on there. But unless there's some fundamentally new technology, we're basically going to see the end of that growth of more smaller transistors.
But it doesn't mean that people aren't still shoving lots of devices together and connecting them with networks. It just means networks become more important. Okay.
And by the way, vendors are moving to 3D stack. chips and all sorts of cool ways of having a single device have even more transistors on it, even if Moore's law is ending. So I have no doubt that things are going to continue quite a ways into the future.
The other thing is storage capacity keeps growing. We've got various Moore's law-like graphs of storage. Society keeps getting more and more connected.
And so we have more devices, more storage, and more devices. More storage, more people means more need for operating systems, which is why you're in the right class. Network capacity keeps going up. Okay, people need more connections.
Okay, and they're at the small scale and the large scale. But not only PCs, we have lots of little devices. We've got lots of Internet of Things devices. You saw this graph earlier I showed you, but we've got little temperature sensors. Fitbits and things you carry on your body and things you put in your cars and all the way up to the cloud Okay, so what's an operating system again?
It's a referee. It's an illusionist It's glue that helps us build these huge interesting systems And that's what you're gonna learn about this term the challenge which I'm gonna kind of close with the challenge is complexity Okay applications consisting of many software modules that run on many devices implemented on many different hardware platforms, running different applications at the same time, failing in unexpected ways, under attack from malicious people, leads to craziness and complexity, right? And it's not feasible to test software for all possible environments and combinations of components.
And so we're going to have to learn how to build these complex systems in ways that basically work. And some of that is going to be learning just how to design systems that are correct by design rather than correct by accident. Okay? The world is parallel. If you haven't gotten that by now, here's an example from 2017, the Intel Skylake.
28 cores, each core has two hyperthreads, so it's 58 threads per chip, and then you put a bunch of these chips together, and you get a huge parallel system in a tiny box, and you put a bunch of boxes together, and pretty soon you've got the world. Okay. Yes.
And 28 times two is not 58. Very good. So with that, not only do we have the chips, which are interesting, but I want you to realize that the processors are only part of the story. It's this, all of the IO is the interesting parts. And we'll talk about that, but it's not just this processor up here. It's everything connected to it.
It's the devices, it's the networks, it's the storage. Okay. So this is. interesting complexity when processing hits the real world and that's where the operating systems get involved. I thought I'd put up this graph just to leave you with a few things to think about. So here is millions of lines of code and if you look at the original Linux, not the original Linux, but version 2.2, which is quite a, you know, 15 years ago, whatever at least.
And you look at the Mars rover, these are on the low end of this scale. But now you kind of look at Firefox and Android and Linux 3.1, which is a little bit older now, and Windows 7. And then you get up into kind of Windows Vista and the Facebook system itself and macOS. And then you look at mouse-face pairs here.
That's a genetic thing. That's 120 million things. You can see that.
Our systems are very complicated. Okay. And so you can go, by the way, to this source and get yours, you know, select the things you want and look at this yourself.
Okay. This information is beautiful.net visualizations and million lines of code. It's kind of fun to look at. Okay. So, you know.
The Mars rover, here it is, is very amazing. There have been a couple of instances of the rover, but this particular one, one of the first ones, was pretty amazing. They were able to send it up and land it on Mars, and it ran for a decade or more.
It had very limited processing. It's 20 megahertz processors and 128 megabytes of DRAM and so on. It had a real-time operating system. But for instance, you can't hit the reset button or you can't debug it very easily. And however, they were able to set it up in a situation where they could, they figured out some timing problems they had and they were able to debug it and repair it remotely, which is pretty amazing.
And I'll talk more about that as we go. But you need an operating system on something like this because you perhaps don't want it to run into a ditch while it's busy taking scientific data or whatever. And so very similar kind of to the Internet of Things in its size. So this kind of processing is par for the course for really tiny devices.
And so we're going to talk about this kind of device in addition to the really big ones as we go. So some questions to end with. Does a programmer need to write a single program that performs many independent activities and deal with all the hardware?
Does every program have to be altered for every environment? Does a faulty program crash everything? Does every program have access to all hardware?
Hopefully the answer to this is no, and we'll learn as the term goes on. And operating systems basically help the programmer write robust programs. So in conclusion, to end today's lecture, operating systems are providing a convenient abstraction to handle diverse hardware.
Convenience, protection, reliability, all obtained in creating this illusion. for the programmer. It coordinates resources, protects users from each other, and there's a few critical hardware mechanisms like virtual memory, which we briefly brought up, which we'll talk about, that help us with that. It simplifies application development with standard services and gives you full containment, full tolerance, and full recovery.
So CS162 combines things from all of these areas and many other areas of of computer science. So we'll talk about languages and data structures and hardware and algorithms as we go. And I'm looking forward to this term.
I hope you guys all are having a good first week of class and we will see you on Monday. All right, ciao.