Yes, Latentio. Thanks again. I appreciate your attention for the next 15 minutes or so. Again, I am Carl. I answered your questions, comments, complaints on this. The second part of this week's series of lectures on this, today's is going to be a little bit more conceptual than either Mondays or Fridays on that. We're going to be beginning by kind of doing a quick review of what we talked about on Monday. And then go over to a little bit about, if you will, the genesis behind the concept of, where did these modern preemptive, multi-tasking operating systems come from? What's the background to them? Why do we need to come up with them? Kind of some of the motivations that, if you will, led to the design decisions that produce current, well, macOS windows, UNIX, what have you on that? And then the balance of today's class is going to be, if you will, a little bit. We talked about this on Monday. The CPU and how it can be multiplexed. Other parts of the class are going to be talking about how other parts of the system resources, like memory and disk drives, can be multiplexed. But we're going to be talking about the CPU today and some of the mechanisms for how that actually plays out on that. So in terms of, there we go. Interrupt handling. Remember I had mentioned this last class, that essentially all interactions with the kernel begin with some sort of an interrupt. And again, I do apologize for the terminology. I'm somewhat sloppy. Interrupt, trap, exception, error. They're related. They're not quite the same. But whatever you call this thingamabob, everything essentially begins with some sort of an interrupt on that. Again, be it page fault, be it hardware, what have you. And what happens again with an interrupt on this? We go back into privilege mode, because we talked about, remember, we've got these two modes, if you will. We've got kernel privilege mode and user unprivileged mode on this. And we want to kind of keep the twain separate on that. And it's easy for the kernel to demote a user process. But again, the tricky part is, how do we get back into privilege mode on that? Essentially, the only way we can is through this, if you will, interrupt thingamabob. And it's kind of burned into the hardware whenever there is any sort of an interrupt, be it again page fault, syscall, what have you. As part of that, the privilege is raised back up to privilege mode on this. So why is that not a problem? Why can we allow untrusted user code simply to execute and interrupt and not have it potentially muck up the system? And we said that, essentially, it's this last point here that's the key here. Yeah, you can interrupt into interprivileged mode anytime you want, but you really don't have any control over what happened after that. Specifically, if you will, the kernel, I'm sorry, the system is going to start running, well, code from a fixed point in memory that user code can't change. And what's that piece of code in memory that runs when we have an interrupt? It is the, well, that can cause us to run this. OK. I'm sorry? Yeah, exactly right. OK, so a syscall can cause us, or a page fault or what have you, can cause us to go through this thing. And this fixed memory location, that points to the interrupt handler. And that piece of interrupt handler is in the kernel, and that's why the kernel still has control over everything that's going on. This kind of review of last week, I'm sorry, last class makes sense? Yes, no? See, OK. I should say point two I glossed over earlier, recording the state necessary. We're actually going to be dwelling a lot on that towards the end of the class about what this state is and how we go about doing this. Question? That's what I was curious. That's exactly right. In other words, what is this quote unquote state that I glossed over? Part of it is exactly as alluded to, this is where this trap frame gets populated, and we'll see how and why that's important. OK, other questions? OK, review making syscall. Ah, there we go. OK. Everything begins with an interrupt. We go to the interrupt handler, and again remember we have to determine what type of interrupt. One of those types of interrupts could be a syscall. It could be a page fault or what have you, but we're focused today on a syscall because that's also going to be the focus of the assignment two on this. It goes to the syscall handler, and then before it actually gets to that though, OK, how do we actually pass to the syscall handler the stuff that it needs to know what to do? This is actually something that goes on in user code here. So to access kernel system call interface from an application here, we have this thing down at the bottom called a syscall instruction, and again that's simply a machine language opcode. Again, it's OC in the case of MIPS on this, and this says generate and interrupt. But it doesn't tell me what type of syscall I want. That's why we're the stuff in the first two points here, OK? Namely what we have to have some information about the arguments that we're passing to the syscall. That's where we've been talking about in recitation about remember you have to save out the arguments A0, A1, A2, all that stuff, because you can think of a syscall as being a fancy-schmancy function call. And as a matter of fact, that's how it looks like in user code. If you call, let's say, syswrite from user code, from user code it really doesn't look any different from calling, let's say, a library function like printf on this. Behind the scenes, there's some magic that's going on, and this is exactly the magic. We've got this syscall opcode, but we've got a kind of nestled in with some other information, namely the arguments that we pass to, in this case, the kernel. And of course, most importantly, the identifying number, because the syscall handler, when it sees that it has to handle a syscall, well, which one? OK, is it sysfork? Is it syswrite? Is it sysfoo? Whatever it happens to be. So again, kind of layers to what's going on. We start with an interrupt. We have to determine what type of interrupt it is. If it's a syscall interrupt, we go to the syscall handler, and then the syscall handler decides where to go from there. And it does this based upon this additional information, namely the parameters. And most importantly, you can think of the syscall number as being kind of a type of parameter on this. Make sense? All righty. OK, software exceptions, hardware exceptions, software interrupts, all this stuff here. All right, I should say this. This is, again, where I've been a little bit sloppy, interrupts and exceptions on this. But a quick version is you can think of some of these things being voluntary and some of them is being non-voluntary on this. And you can think of it, what's an example of where I would want to generate an interrupt? As a matter of fact, this is what you're doing right now. I manually put in, I want an interrupt, please. Exactly, right? Sometimes there might be a reason why we might want to generate another. But by and large, these other things are like, hey, well, actually, the process just divided by 0 or tried to divide by 0. And immediately, the CPU will trap that and say, Colonel, what do you want to do? This is a really bad error. Or another example of an involuntary interrupt is something like a page fault on this. You'll know point or dereference on this. I try to reference invalid memory. OK, that's going to cause a problem. The upshot is the user program didn't necessarily plan or want to do the interrupt. Clear on the distinction here, in other words, it's basically sometimes a user program wants to generate an interrupt and sometimes stuff just happens, as they say. Why are we going through all this here? Well, OK, we talked a little bit about multiplexing here. And we want to actually see, again, how this ties in with the genesis of modern operating systems, again, what you have with either WinOS to wash my mouth out with soap or Mac OS or what happens on this. Preemption, context switching. The reason that is important is these are some of the tools that we're going to be using to implement CPU multiplexing. So for the terms, preemption and context switching, that's something, definitely when it comes time for something like the midterm of the final, you want to have a handle on all these things. You know vaguely it has something to do with saving out state, but you want to know the mechanisms. And let's see what we can do with this. OK, here. Problems, we talked about this last time here. Ah, there we go. OK, CPU limitations here. Essentially put, we have way too many things chasing one poor little CPU on this. Or even on contemporary systems, your laptop probably has maybe four, eight CPUs or whatever it is. But we know one thing, that number of tasks, threads, processes, what have you, is probably going to be way, way more than the number of CPUs that are out there. This is a reason because, well, again, why don't we have 1,000 CPUs? Actually, there are computers that do have 1,000. There are computers that have 1,000,000 CPUs on that. They're really great. So why don't we have 1,000,000 CPUs in our laptops? Huh? You can't afford it. Probably in terms of money, but also, it's going to be one big laptop that you're going to be hauling around. OK, you're going to need probably some turbo cooling liquid system or something to keep the thing from, well, frying your legs on this. So basically the upshot is too many things, case chasing, too few processors. So even though we do have more processors than one on typical computers, what that means is we still have to, if you will, divvy up resources among these fewer CPUs on this. OK, oh, yeah, again, graphical illustration. It's kind of musical cheers. Maybe we have eight cores, but you know what we've got. Whatever that is, greater than eight things chasing that. And essentially what that means, we can have eight happy processes running at any given time. And everything else is, at least for the moment, frozen out. All right, CPU limitations here. OK, I should say this. What? Limitation? I thought being faster is kind of something that's good on this. Because if you think about it here, you know what? CPU, it's faster than memory. Remember from 341? OK, Christianler talking about like caching. That's why we have caches. Because the CPU way, way outstrips memory speed on this. OK, way, way, way, way faster than disk on this. If you wait on disk IO, you are going to be twiddling your silicon thumbs for millions, if not billions of cycles, waiting for the disk drive to get back to you on this. And certainly far faster than you as an individual on this. So this to me, it kind of sounds like it's a good thing for the CPU. So why is it necessarily a problem on this? Well, OK, what? Ah, yes. More on just the concept of, if you will, the fact that these CPUs are just really, really fast on this. If you talk about it in terms of, let's say, what's a gigahertz, you can see that essentially it's, well, here we are, millions to billions of clock cycles to do stuff that even as a human we can barely perceive. Be it video processing, be it audio processing on this. Again, the point of these two slides is CPUs, the physical silicon processors, are essentially way faster than anything else on this. And this is a slide from way back when. And you can see they are actually hooking up wires to big, big computers on this. Why is that relevant? Let's take a step back in history and talk about how computers were in the land before time and how we get to modern operating systems. So basically, computers did one thing at a time. Because if you think about it back when, putting a computer together like this, they had individual vacuum tubes later on, individual transistors, what have you on that. They were not just extremely expensive. They took a lot of electricity. Even, I mean, they had problems with, let's say, literally wires separating, burning out, transistors frying out. They were expensive. So even the concept of a processor itself was extremely expensive, very difficult to implement on this. So we probably only had one processor to the extent that you can even think of it going on here. What's more important, though, is that we were doing one thing. How do you interact with a machine like this? I don't see any liquid crystal display. I don't even see a CRT on this.  But at the beginning, you literally hardwired the wires to program. That's how you program the machine, was with wires. And then later on, they got this nifty idea, hey, let's use punch tapes, those 80 column punch tape things. Do not fold, bend, spindle, or mutilate on this. And you had to feed it through a reader. And then the computer ran your program. And then the computer gave you a printout. And it was probably, you know what, syntax error. So you as, I'm serious, this is what life for programmers was like back in the Cretaceous era. In other words, you would spend several days, because of course, you weren't allowed to actually edit on the machine.  So you would have to kind of type things up, give it to the secretarial typing pool.  The operators would feed it into the machine. And of course, there's going to be bugs. So then you would have to take the results back, figure out where in your printouts there might be a bug, take a guess, and then that was the, if you will, the iteration of developing programs on this. So it was still better than adding things up by hand. So how can we actually, OK, essentially we are doing one thing at a hand here. So how can we actually improve this thing here? One thing is, let's see if we can't have this computer maybe use multiple users on this. Because while you are trying to figure out the source of that syntax error, maybe someone else can run this program and try to find out this is a syntax error. So we're going to kind of try to alternate back and forth between two syntax errors on here and maybe eventually solve one here. Now one thing here is that there are abstractions and no multiplexing. Why do we not have to worry about multiplexing at this point in time? Because are we running how many things right now? Exactly. So at the beginning, we have one huge expensive computer. It does your batch and only your program at a time here. So we do have the concepts of like IBM came out with disk drives in 1956. So you had file systems going way back when.  But what you didn't worry about because they just didn't exist was multiple users on this. So again, one thing at a time and since we're dealing with one thing at a time, you don't have to worry about this thing. OK, here. Again, I think it is one long, really long irritated queue of people waiting to get their time on a computer. And this was often, there were many, many petty squabbles at places like IBM and whatnot of who was most important to get to the head of the physical line of programmers waiting to get their deck of IBM cards fed in and run the computer on this. So how are we going to actually make this a little bit better? Oh, yes. Let's actually see if we can't maybe have multiple people use the computer at the same time. Or can we do that? Well, let's talk about this. Essentially, this is where an operating system comes in. Back in, again, the Cretaceous here, or even when I was young and I was using 8-bit micros on this. An 8-bit micro essentially has things like a file system.  And it has a CRT monitor. It has a lot of the tools that modern systems have. But what it does not have is an operating system. Reason being, well, there was only one user. But what else was going on? Not only was there only one user, I was only doing one thing at a time. So when I was playing Little Brick Out, which was Steve Wozniak's version of Breakout, that's all it was doing. And that poor Apple II didn't do anything except run Little Brick Out in basic on this. So it didn't have to switch back and forth between that and what I was torrenting over the internet or what have you. So again, we didn't need an operating system. All I needed was a bunch of tools. Make sense? The operating system comes in when I want to get into the concept of multiplexing on this. Scheduling to meet the needs of computer users here. Now, originally, what we want to do is schedule the humans not the computers. This gets back to what we were talking about earlier. Here it is, batch scheduling. Remember what I was saying is we've got these really cranky programmers that are really like a bunch. Well, they're caddy about how much time they actually get. Think of it as I want to run just Firefox. I can't do anything else with my computer. And then just a terminal and then just whatever that happens to be. I don't know these modern icons. The upshot is that we're doing one thing at a time. So I don't need an operating system with that. What's the problem with that? Or what are some of the problems with this approach? I want to run one program, then another program, then another program. What do we not like about that? Now, it takes a long time. I mean, literally, because we're going to have to have humans kind of feed the, if you will, the deck in. We don't have it automated, exactly, right? Are there problems? OK, yeah, let's talk about that here. I'm running Firefox here in a browsing session. And let's say that Firefox needs to retrieve a graphic off of the hard drive or something like that. Well, we know that the CPU is faster than the hard drive. So the CPU is going to be twiddling its electronic thumbs, waiting for that hard drive to load up the picture. What this picture on the screen right here glosses over is, yeah, it's running Firefox during this time slot. But you know what's going on during this period of running Firefox? There's a lot of downtime, at least for the CPU. Makes sense? So you can kind of think of this as being, if you will, invisible periods where it's officially running Firefox, but it's just waiting. And this is a huge problem on this, especially back in the day. I mean, literally, every millisecond, every microsecond, had a big cost to it. So if you were a computer manufacturer, if you were, let's say, a company that has a mainframe, and you heard that your half a million dollar mainframe was sitting idle, essentially 12 o'clock hours of the day when you added this all up, the CFO is going to have a fit on this. What can we do to kind of make this more efficient? So batch scheduling is simple to implement, but yeah, it is inefficient on this. I said earlier that being fast is good, but why is it a problem here? Exactly this. So kudos. This is the problem with being faster. It's not so much that it's a problem itself, but there is a lot of downtime, and the owners of these expensive computers did not like that at all. It's inefficient. Questions, comments? Does this make sense? OK. Solution, operating system here. What we're going to do, and maybe it's a little bit difficult, but let's pretend here that this Firefox session is actually one session. In other words, it's not one person googling Google and another one googling Nutscape, whatever it happens to be. And let's say that it's one person, and then at this point in time where this arrow is, we need to retrieve the graphic from the disk drive. So at this point, the CPU starts twiddling its electronic thumbs, and you know what we say? This is a waste. While the CPU is idle, I'm going to see if I can't maybe get some work done with something else. OK, I'm not done with your session. I'll come back to it later on, but I will do something else. Now that CPU is being put to good use. This is the concept of, if you will, time slicing, and we're making much better efficient use of the CPU on this. So later on, let's say the disk drive has finally returned what needed to that graphic. I can now, let's say, return it and the CPU can do whatever magic it wants with it. Make sense? All right. There we go. There we go. Basically, high delays. Keep the processor active on this. And by the way, at this point in time, we probably only had one processor on this. Oh, this is important too. In terms of co-operative, I had alluded to this on Monday's class, but there is a flavor of, if you will, kind of arranging how to do things, cooperative multitasking. In other words, this gets back to the whole thing about why do we need the police department and jails and judges and whatnot. Everyone obeyed traffic laws. Really, we would not need that here. So you know what? If we have cooperative scheduling, all the threads play nice with each other, and they never try to cheat each other on this. You know what? We really can get back, if you will. All we need to do is just have the threads cooperate amongst themselves. We really don't need a policeman to kind of club one thread over the head and say you're misbehaving on this. There we go. OK. Oh, multiple interactive users. By the way, what we're trying to get over with this particular slide here is there's different, if you will, different ways that we can have different time slices. We can have, let's say, one user running a whole bunch of different tasks, which is typical for pretty much everyone nowadays.  So you're doing two official things, but you know what? You probably have pulled up Task Manager or PS. There's a lot of other stuff that's going on in the background, so even you one user are really responsible for a whole slew of threads that's going on. Add to that additional users, OK, and what you wind up with is number three here. Essentially, what we have to keep track of and ensure fairness and make sure that the whole system doesn't blow up is lots of users, each running lots of threads. So we've got, in effect, if you all think of it as, let's say, O of n squared tasks that we have to keep track of. And this graphic right here, what we're trying to do is we have, if you will, let's say, this Firefox session. We pause for a graphic and here it starts up again. But now we have, if you will, we're getting into something. Namely, you know what? We had that one processor. We're going to possibly start throwing on the equivalent of another processor. So we have, at this point, the concept of, if you will, not just time, but even at any given point in time, we're going to start to do more than one thing at a given moment in time. I wish I had. There we go. OK, illusion of concurrency. Has Jeff talked about this in previous weeks yet? OK, so real quick review. Essentially, if you have only one CPU, let me be clear about that. Let's say only one CPU, strictly speaking, there is nothing going on simultaneously. There is something going on concurrently. Let me be clear about this. Difference of simultaneous versus concurrent on this. When we're talking about simultaneous, I mean something that what is going on at any one instantaneous point in time. So if we have one CPU, it's doing one and only one thing. As opposed to concurrent, we already have, let's say, 10 processes that we're alternating among. So in other words, within a fairly short period of time, we are at some point touching or running a whole bunch of threads on this. So illusion of concurrency comes back because we as humans can't perceive this. It's kind of like the light bulbs flicker 60 times a second in the case of incandescent. We don't notice it because our brains are simply too slow to keep up with it. Same thing with the computers on this. There we go. OK, again, more on this. Here we go. Human perceptual limits here. Essentially, if we are alternating between two processes, we can't tell the fact that we're really only running one or another at the same point in time. These switches, the term for that, context switches. And the actual point at which we switch from one to another, how does that happen? If we're switching from, let's say, thread number one, running Firefox, the thread number two, running some sort of a terminal here, we have to switch out the context of a thread, more on that in just a second here, to the context of another thread here. And at the point at which this switch actually happens, how do we affect this switch from one to another? So the CPU is running one thing. We need to kind of, in effect, junk what that CPU is doing and replace it with something else, interrupts. This is where this all begins to tie together here. So in other words, if I am running process foo, and let's say the operating system decides, you know what, I want to run process bar, how am I actually going to go about doing that? Well, the operating system says, you know what, foo has run for long enough here, so I can do my magic and switch things over, more on the exact magic in just a minute or so. So question here. How do I actually, where do these interrupts come from here? Well, we were talking about this. There could be any number of sources of interrupts. You could have, let's say, the disk drive says, hey, you know what, the data you wanted is ready, so I'm going to poke the interrupt line. Or you could have a memory fault. Or you could have a sys call. In other words, the thread foo could voluntarily say, I need help. It falls into the kernel, and now the kernel gets control. But what happens, let's just play what if here. Let's say that there is no page fault. Let's say that process foo, it does not schedule any or run any sys calls on this, or what have you. Let's say that process foo is just being obstreperous and wants to be piggy about not wanting to let go of its time slice. How do we enforce? Again, this will work great as long as foo and bar cooperate amongst themselves. Back in the days of cooperate multitasking, we have to count on foo calling a yield function to kind of give up its time slice, if you will. But we can't necessarily do that. Why do we need this, if you will, police officer mechanism to enforce it? And how does that actually work? If we're not generating interrupts ourselves, how can we make sure that an interrupt actually happens? You know what? Let's go on here. Timer interrupt. In other words, there's one hardware interrupt that we know for sure will happen. This is the purpose of the timer. And again, you can think of it. It's sometimes dealt with separately, but essentially a timer interrupt is a type of hardware interrupt. It essentially says, we're going to have an interrupt for the sake of having an interrupt. And that is how the kernel knows for sure that it will eventually get control. And at that point, we can see, well, is that time slice really up? Maybe it isn't. Maybe we need to schedule something else on this. So we can count on it. When the kernel voluntarily relinquishes control to a user process, the kernel can be sure that it will, at some point in the not too distant future, get control because of a timer interrupt, also known as the timer tick on this. And on most systems, what happens is it's set up. There's like a quartz crystal that essentially, however many milliseconds or nanoseconds it fires. You know, boom, boom, boom, boom. And it's constantly going. It never stops on this. You can also schedule some additional timers to fire if you want to. And sometimes threads do that. They say, you know, kind of give me a poke in five minutes or something like that. And that's something you can voluntarily do. But something that's already kind of preset up by the system and that the operating system counts on is that there is a constant firing of, if you will, these timer interrupts essentially forever. Never stopping on this. OK. And this, people, is the difference between preemptive multitasking and cooperative multitasking on this. In cooperative multitasking, we're counting on the threads to play nice and calling that yield function on this. In preemptive multitasking, I don't care. If they want to cooperate or not, they are eventually going to get bumped on the head. And I'm going to get control on that. And I can see whether or not that thread is mispaving on this. And what happens when a timer interrupt fires? Goes through the same process as everything else. In other words, we go to the interrupt handler. What type of interrupt handler is it? In this case, it's a timer hardware interrupt. Well, if it put this way. If the interrupt were, let's say, the disk drive and it said that bytes were ready for you, you probably want to go to the interrupt handler for the hard disk. In the case of a timer interrupt, we want to go to think of it as the handler for the timer interrupt, which is what. I just talked about this yet. What's, in effect, the handler for a timer hardware interrupt? This is going to be a huge part of the course later on. So maybe I'm jumping ahead. Scheduler, scheduler, if you're north of the border. So in other words, how we handle a timer interrupt is, how do we want to run next? That's the point of a timer on this. And there's all sorts of funky algorithms as which types of threads to pick and what order and how much time to give them, et cetera, on this. Questions on timer interrupts? Yes? A question on context switching? Yes. Even if you still have just one processor and one processor has multiple threads, is context switching the one that enables the illusion of concurrency among multiple threads in a single process? It's part of it, certainly. In other words, context switching, the question is, is context switching what enables the illusion of concurrency? Is that kind of OK? It's part of it. It's necessary. It's not the complete picture. In other words, we need context switching to, in effect, take one thread, stop it. And remember in Star Wars, Han Solo gets put in the carbonite freezer. And then later on, when we want to reschedule that, we need to kind of hopefully Han Solo has survived the freezing process on that. Princess Leia would have been very disappointed. So what we have here is the context switching. The mechanism or point of context switching is to make sure the thread survives the carbonite freezing process. We need to save enough stuff so that it can kind of reanimate itself and continue on without figuring out, where am I? I don't know who I am. That's what the context switch is. It's the stuff that we need to save out so that we can, in effect, resume later on. That's necessary to provide the illusion of concurrency. The other part to it is, well, cool like what we have to do it fast enough and have enough, let's say, AV eye candy to make it appear to the user that this is all happening simultaneously on this. Kind of like, if you will, like a movie projector as in old-fashioned movie projectors. Remember, it displays one transparency, and then what is it, like 1, 24th of a second later. It pulls another one down, yada, yada, yada on this. So in other words, the context switch is the mechanism to switch threads back and forth, and that is a necessary tool that is a component of the whole bigger picture of context switching. Answer your question. Other questions? OK. Ah, here we are. OK. Ah, here we are. Oh, yeah. OK. By the way, this is tier two. If Jeff has not hammered this home, OK. Really, really important, threads can be stopped at any time on this, and they can be restarted in any order. That is why you people have been tooling around with these things called locks and condition variables and whatnot. You can't ever guarantee when a timer might or might not fire. It's really good that we now have all these CPUs. It's great that the electrical engineers now give us, as programmers, multiple CPUs we can crunch more data. The downside is it's a real pain to program these things. And we already had problems with timers firing at any time. We now have additional problems of multiple CPUs with multiple timers, and we got to synchronize this whole can of worms on this. And that's going to be a large part of subsequent lessons on this here. OK. Oh, here it is. This is exactly, actually, this is your question earlier here. OK. We wanted to appear that nothing has actually happened. Yada, yada, yada on this. So we want the CPU state to be identical on this. In other words, let's actually talk about the mechanics of this context switch on this. I think this is, yes, here we go. OK. Thread state, what actually do we need to stick into carbonite to freeze it? Well, obviously, one thing, the registers. Why do we need to save the registers on this here? Because remember, you took a look at, you may have already the context switch and the interrupt code. What's the first thing that gets saved out? Yeah, trap frame on. The registers get put on this trap frame. And we need to do this right away. Why? Because what are the registers? They're just kind of variables that are stored internal to the CPU itself. If I don't save out those registers, what's going to happen as I continue along running my code in the interrupt handler? Yeah, right? So the first thing I have to do is, if you will, save a pristine snapshot of where things are at this point in time, now I can go on and kind of start reading the rest of my code here. The other thing that I'm really interested in is, if you will, the stack itself. Think of a thread roughly put as an execution context here. In other words, this is what, if you will, the system, the computer needs to kind of swap around among, well, how can I run different things at the same time here? Again, think back to like compsci 115, 116. Remember Carl Alphonse talking about, let's say, object variables, static variables, and local variables on this. Why do we never need to worry about synchronizing local variables? Maybe I'm ahead of myself on this.  You don't need to synchronize local variables. Why not? They're private to the stack. Right. It's private to a thread. And what do we mean by that? Local variables are stored where? They are stored on the stack. And each individual thread has its individual stack. So that's why we don't have to worry about synchronizing local variables on this. One thread does not munge on another thread's stack. Well, if it does, we have a huge problem. But that's another story. So essentially, thread state is registered stack. There's some other metadata. If you haven't already, take a look at, let's say, that these threads struct in, I think it's like thread.h or whatever it is. You don't have to know it deeply, deeply, but you should at least be tangentially familiar with it. OK. Oh, yes, and one last comment here. How the stack actually gets taken care of is, well, that's the job of the operating system to make sure that the stack is saved in a place that is safe and won't get, if you will, mucked around with. OK. Ah, here we go. Let me get a minute here. Actually, I already covered this here. Basically, when a timer fires, the first thing we have to do is save out the, if you will, the registers. And the registers get saved out on the trap frame. And by the way, where does the trap frame get put? What do we have here? We have essentially two things for a thread. The registers and the, we want to save out the registers. So what's the police of memory that I do know that I can use that's private to me? Exactly. So that's where our trap frame gets crunched.  Now I can run my interrupt handler on this. OK. This already is, if you haven't done so already, you don't need, again, you never have to run, I'm sorry, write operating. Try this here. You people will never have to write machine language for this class. It does help to, again, be somewhat familiar with some of the assembly files on here. But in the exception, this is the assembly language program that gets run whenever there is, if you will, a trap or an interrupt. This is what gets run before trap.c. And what's the first thing that happens here? Save better registers. And you can see, we're actually saving register 98. What have you. And we're pushing them onto the stack, yada, yada, on that. By the way, what probably happens when you are returning? You're done with this trap. Yeah, exactly. You've got to restore that. Again, we've got to restore Han Solo from carbonite on this. In other words, we take the stack. We're assuming that it has not been munged on because the operating system is tasked with making sure that this thread, if you will, stack has not been touched. And we can pull these registers off, and then away goes our thread. Make sense on this so far? Oh, here it is. You can see there's a whole bunch of these things here. Ah, context switching. OK. What is a context switch? Roughly speaking, it is switching the thread state from one state thingamabob to another state thingamabob here. And what does that state consist of? Blank and blank. Blank, stack, and registers. Exactly right. So that's what we need to switch when we go from, if you will, one thread to another on this. Now let's say that I was in the kernel when a timer fires. That's going to be a piece of cake here. All I need to do is save out the registers, switch the stack, restore the registers, and away we go. Very simple on this. Add an additional layer to the kettle of fish if we are in user mode, though. And the problem is, remember the just slide about no trust or user or whatever it was there? Basically, the user has its own stack in user mode. There is a second stack for each process that is in the kernel. Remember again, take a step back. What's the difference between a thread and a process? A thread is an execution context, simply put. A process is one or more threads that share, if you will, a user context. And part of that user context is, if you will, a user address space. In other words, we've got a user address space with a user level stack, but we always have underlying that a kernel stack on this, too. So just if it seems a little bit confusing, there are two stacks for each process, if you will. All righty here, bunch of different reasons. Obviously, we want to keep them separate because we want to make sure that the user cannot muck around with anything related to the kernel on that, too. Oh, this is actually good, too. I asked earlier about what potentially happened. What happens when interrupt fires? First thing we do is we save out all the registers, yada, yada, yada. And what happens when we return? Again, we restore the registers on this. Jeff is posing a question here. Where can we find this? Do we have this code? Yeah. Treasure hunt. Actually try to find it. We already know where the code is to save the registers in that exception, whatever it is, file on that. And we had that in a couple slides back here. Take a look and locate later on the code that of, if you will, loops back up and restores Han Solo from Carbonite. Questions? Comments? Yes? Why does every processing have two stacks instead of the kernel stack, just because the kernel is going to be doing the same thing with only different arguments? Right. OK, the thing is that would be assuming that we have, in essence, one thread on this. In other words, let's say within the kernel itself, we are currently in the middle of reading the disk drive. So we're in, let's say, VFSread or something like this for one thread. But another thread is doing something else completely different. Let's say that it's writing out to the screen, if you will. So I'm going to be executing two different pieces of code. Makes sense. So in other words, where I am in terms of subroutines, it's going to be completely different. Does that answer your question? Other questions? Oh, I should say this also. Again, you're not responsible for implementing multiple threads in your processes for OS 161. Obviously, production operating systems do have multiple threads. So let's say that I had in Linux, Linux, Linux, however you say it. Let's say one process, and let's say that it has two threads here. How many total stacks is that process going to have? Two what? Well, I've got one process, but I've got two threads. And then for each thread, in effect, I've got a user stack, and I've got a kernel stack here. So I'm going to actually have four stacks that I would have to kind of keep track of. So for each thread, it goes up by plus 2. Even though you share the same address space, again, this is why we don't have to sync local variables on this. Because those local variables are on what the stack in user land for that particular thread. So they share the same global space, but not the same if you will stack. OK, other questions. We were a couple minutes early. Actually good for change. Questions I can answer for you about class so far? Threads, processes, interrupts. General stuff about OS 161. Check, 0.2.1. Yes? So you're saying, for a particular thread, there has to be a maintained additional kernel stack because, one, the thread is making system calls that requires a stack in addition to the user stack that is doing user stuff. Correct. Yes, again, to reiterate, for each thread that has a user context, you have two stacks. Correct. So in other words, I'm using my one stack while I'm in user mode. As soon as I trip to, I hit interrupt and I switch to kernel mode, I switch stacks. And I use my individualized kernel stack. That's why I say, for each thread, there is two additional stacks that is created and have to be tracked. There was a question over here? People, if we could have one conversation, we're almost done. Thanks. So when we switch to kernel mode, does all the data that the thread is currently having get copied onto the kernel mode? Kernel's user space or what specific things will be copied? OK. What happens when we switch to kernel mode? OK. Well, we're running in user mode, and we're using the user stack for that thread. We hit interrupt. So we immediately go to the interrupt handler. And what's the first thing that the interrupt handler does? It saves out the trap frame. And by the way, it puts the trap frame on which stack almost. It doesn't trust the user. So the trap frame gets crammed onto the kernel stack. So it does whatever it needs to do in kernel mode. Now it's using the kernel stack. And then before it returns, it pops the trap frame to restore the saved user level registers from the kernel stack. And now it can go back. The last argument, as a matter of fact, take a look. Remember, Jeff had the one slide up there. He said, go find the return from exception code. If you do that, you'll see the last register to be restored, essentially. It's the stack pointer to switch back to the user level stack. And now we can pull, if you will, our variables and whatnot from the user stack that we were using. Answer your question on that? Other questions? Yes. So you use the term context switching for like inter-process concurrency. I was wondering, do you still use the term context for like inter-process concurrency switching between threads? Excellent question. Everyone hear that? In other words, what do we mean by a context switch? Essentially, everything. In other words, if I am switching from one process to actually even within that, essentially, let's say, I am in, let's say, a kernel-only thread that doesn't even have a user context, and I switch to another kernel-only thread, that's a context switch on that. In other words, if I am switching, let's say, from one user-level process, I have to trap into the kernel switch to the kernel stack. Then let's say I switch to another kernel stack, which has a user process, and then I switch back to that thread, if you will, user context. That is also, if you will, a context switch. So in other words, the context switch, you can think of it as happening when we're going from, let's say, one, if you will, kernel stack to another. We could even argue, if you will, it's a type of context switch going from user land to kernel space, if you will. Because what are we doing? We're switching stacks. We're saving out, if you will, registers, and we're moving over to a user stack on this. Strictly, I mean, where you most often think about it, and this is like where the scheduler comes into play, it's always from the kernel stack of one threaded to the kernel stack of another on that. As a matter of fact, take a look, there are two types of, if you will, places where registers get saved out in OS 161. We've already talked about one. That's the trap frame. That gets stored whenever there is an interrupt that fires. There is another batch of variables that gets stored whenever we switched from one context to the other. That's the switch frame. So we've got, if you will, the trap frame that stores variables whenever we have a trap and we have a switch frame, which, if you will, is what gets crammed onto the stack whenever we do a switch. Make sense? Other questions? Oh, and I should say, strictly speaking, you know what we call is the switch is when we switch one stack pointer to another. Because now we're looking, instead of this stack, we're looking at another stack. Questions, comments? All righty. Oh, yes, one last question. And then? Will we have, will we also have two? Good point. Are there any such two, are there any such two? OK, in other words, how many trap frames do we have? Essentially, we have as many trap frames as we have nested levels of exceptions. That's an astute question too. Because in other words, we could be running in user mode. And let's say a timer fires. So we push a trap frame onto the kernel stack. While we are, let's say, well, actually, a bad example. Let's say we're in user mode and we do a sys call. A sys call generates an instruction. So we push a trap frame onto the kernel stack. And while I'm in the middle of doing the sys call, let's say I hit a page fault. That is in interrupt. So I'm going to put another trap frame onto the stack. While I'm in the middle of my page fault handling code, a timer fires. I push a third, if you will, trap frame onto the stack. So it can keep going down the rabbit hole as deep as you need to be on this. And then eventually, hopefully we don't blow the stack, we kind of pull these things out as they variously get serviced. Eventually, we'll come back. The scheduler will run me again. So I can pop the one trap frame on. Then I go back to my memory manager that I was interrupted in the middle of. And when I'm done with that, I can pull that trap frame off. And then I can finally go back to my sys call that I was doing to read some bytes from disk.  Make sense? So basically put however many trap frames depends upon however many traps happen. And it can start nesting rather interestingly. All right. I'm going to stick along as there are questions. We're already a minute over. Thanks for coming. Friday.


You're one of the former Yankees with the fun Instagram feed. Are you ready to check it out? I'm ready to check it out. Let's do it. Let's see. First one, doing a little hiking. That was in Malibu, California last year. I went on a seven-day detox retreat type thing. 12 miles of hiking a day, 1400 calories of meal a day and it was a great experience. That sounds like a very healthy trip. With a group of strangers, I never met these people before in my life. So it's just 16 of us and hiking, breakfast, lunch and dinner together. Amazing. So what did you take most out of that trip then? What I took out of that trip was how we ate 1400 calories a day of vegan food and didn't realize I could really survive on that little amount of food. And it just goes to show how much I really overeat in a daily basis. How much weight did you lose? I lost 12 pounds in seven days in that retreat. We walked 12 miles a day. We had two one-hour workouts. So two hours total. Massage and yoga every day. Amazing. And there you are again doing a little more. That's one of my friends. I met him on the trip. That guy's about to get married. He's from New York. He's a big Yankee fan so he kind of hung out a little bit. Had a great time. You also like to hit the links a lot. Here's a couple cool photos of you going golfing. Yeah. Where are some of your favorite spots that you've golfed so far? Well, those three you just passed here. The first one was Oakmont in Pittsburgh. It's one of the top rain courses in America. They play a PGA event there and it's a really hard golf course. And these guys won an event at an auction and I was included in the auction. So I got to go on that trip. That one there is Augusta National. I was like a bucket list for me for friends of mine in New York again. Called me last year and asked if I wanted to play two days there. Stanley O'Neill. These guys, I really appreciate that and I'll never forget it. That was the Deeders Golf event last year in Las Vegas, Shadow Creek. And that's Canyon Sturz, Brandy Chastain, the soccer superstar and Jorge Posada, Yankee legend. Talking about a foursome. It's a great time. That was down in Puerto Rico last August. I saw this charity event to raise money for the hurricane relief in Puerto Rico. Sure you are. Can't be letting a game. That's to be a legendary Pat Sajak. I didn't know him. He just happened to be sitting right next to me at the game and we had a great time. It's a great conversation. That is a local daytime show here in Tampa. A friend of mine, Jackie Rodriguez, they asked me to host the show a couple times here and there. So I went on and did it for an hour in the morning and it's another good experience. Did your time with Pat Sajak help you with the hosting gig? Not at all. Not at all. Here you are. Tampa legends. Yeah, that's Tom Shannon, a legendary Lupinella. I was up to dinner one night here in Tampa and just happened to run across them.  So he's always great to catch up with and a close friend of mine. Do you guys bump into each other a lot because I know you're both Tampinos? Yes, Tampinos are the Latin group people that grew up in West Tampa. That's where we came from. And Lupinellas from there, my parents are from there as well. And you also get some first pitch thrown in. Here you are with Fred McGryff. Fred McGryff and I actually played at the same time in 2004. They asked us throughout the first pitch to commemorate a local player that played for the Rays here in Tampa. And? Last Fourth of July, you know, we always go out to down Longville, Key and Sarasota and have a great time. My brothers and I and all of our families. Beautiful water around here. So it's nice that you take advantage of it. I see why you haven't left. Yep. I take advantage of it quite a bit. Last one. Here you are, Jean-Carlo Stanton. Yep. That was last year. I never feared it. Last year in screen training, his first year here. Just talking to him, you know, just catching up with him, see how he's feeling out here, getting accustomed to the Yankees, the new team, the new surroundings and just trying to make him feel comfortable because he's a great player and he's a great player for us for a long time. We see all these fun posts that you have. What's your favorite part about Instagram? Well, you know, my fun part is the people I meet and the posts I put in the comments I get. That's really cool to see you with Jorge Posada or so-and-so and whatnot. But also the people I do follow and see what they're doing as well. It's kind of interesting to see where he's at. All right. So here's the time for the plug. Watch somebody follow you and what do you have to offer? Well, I'm not that funny, but I do try. I don't do that. I go to interesting places and I try to post the people I'm with mainly. I mean, that's not really all about me, but who I'm with and what adventures we happen to be on.


Okay, let's get started. Hello, everyone. My name is Yaron Schneider. I am a steering committee member of the Dapper project, also a core maintainer for the runtime. I work at Diagrid, which is a company I started back in January of 2022, and today we're working with lots of major enterprises on their open source Dapper adoption and here with me today. Hi, everyone. I'm Josh. I'm also a core maintainer of the Dapper project. I'm also a software engineer at Diagrid. All right. It's great to have you all here. Just so you know, you're really helping out the project simply by attending this talk because the questions you will be asking us afterwards and, you know, getting to know all of the latest things that are happening in the project really helps us because then you will open up GitHub issues, right? You'll go on Discord and you'll tell us what you like and what you don't like. And this is what helps the project really the most. So let's start talking about what Dapper is and we'll really cover this for people who don't know Dapper. So all the stuff in the middle that you're seeing, all of these different building blocks, those APIs, that's the stuff you don't have to deal with. Service discovery, invocation, PubSub, creating event-driven systems, connecting to databases, PubSub, message brokers, configuration stores, coding for resiliency, fault tolerance, observability, monitoring, monitoring the whole thing, right? Creating resiliency policies, circuit breakers, timeouts, retries, all of that stuff just adds up so much.  And Dapper really takes care of all of the rest. Dapper runs really well on top of Kubernetes or just as a binary, a single binary that can run in your machine. And it'll run pretty much on top of any Kubernetes cluster also if you're running on Kubernetes and OpenShift. And Dapper integrates with your existing stack. So Dapper is not a replacement to your infrastructure. It actually makes it better. It makes it more secure. It makes it more reliable by providing sometimes features that you don't find if you're talking to the underlying database or PubSub or Secret Store directly. Dapper has a vibrant community. We'll talk about that in a second, but we have over 120 of these specific component-level integrations. A lot of them are contributed to Dapper by companies like Microsoft, AWS, HashiCorp, Confluent, and others who want to make the Dapper ecosystem better for developers everywhere. So for each one of these APIs, we'll find a set of components that you can use to connect your infrastructure, and Dapper will provide additional security and reliability guarantees on top of what you'd normally find. Dapper has a set of goals. I'm not going to cover all of them, but the most important thing I think, you know, the first is to give developers tools that solve their problems of the day, meaning Dapper is a tool that changes with the time. If there is a new problem that developers, application developers face, Dapper will be set to meet that problem tomorrow, which is why Dapper is continuing to add more and more APIs. And it's vendor-neutral. Of course, it's part of CNCF for an incubating project. Zero trust security is something that's very important, which is why we're listening about as part of the APIs. We think with Dapper, zero trust security goes beyond just service-to-service communications. It's all the way through from your application to infrastructure. There is a lot more to just point-to-point communication when it comes to zero trust. You need to think about your whole stack, and this is something that you will find in Dapper in almost every API and feature that we have. And it's also really important for us to become platform-agnostic, meaning Dapper can run on Kubernetes, but it's important that it can really run anywhere, because people are not just running stuff on Kubernetes. It's a complex world out there. Forward, we have a very vibrant community. The things that matter most to us, the maintainers of the project, is, of course, the number of contributors. Those are the people who give their time and effort to the project, the one who are opening PRs, issues, commenting on Discord. This is really important. We have over 3,300 contributors today, and growing, we are the 12th largest project in CNCF, because Dapper is uniquely positioned to be a very application-developer-centric product out there. Let's talk about Dapper in 2024 and what we're planning. So, Dapper, as you know it today, runs on Kubernetes really, really well, and there's lots of boxes in here, but I promise you it's not as complex as it looks like. There's a bunch of control plane pods that basically manage the data plane, so Dapper runs as a sidecar container to your application so that developers can use those APIs. You basically call on local host, which is where the Dapper sidecar will run, and then we basically have a control plane that manages things like security and security communications between the Dapper data plane and the control plane, and it also lets the data plane know whenever you connect a new database or a PubSub or what we call in Dapper a component. So these are control plane pods, and they run on Kubernetes and the data plane runs as a sidecar, right? So if you have one deployment and that deployment has 10 instances, those 10 instances will have 10 Dapper sidecars. This is great in terms of high availability, because if one of those pods crash, the others are unaffected, they each have their own sidecar, but in some situations that might lead into too many resources being used. You might want to cut down on that, and so I'm happy to say that now instead of having a Dapper sidecar per application, you can actually run Dapper in a mode that's called Dapper shared, and Dapper shared is essentially Dapper pods that can be auto-scaled, can be auto-scaled by KIDA, for example. You can just do an HPA, you can auto-scale it with CPU and memory, and you can have multiple instances of an application talking to a single Dapper sidecar or two Dapper sidecars if you auto-scale them, and so you can save on a lot of resources. Of course, Dapper can also run as a demon set, meaning as a single pod inside of a node. I recommend to do that very thoughtfully, because if that specific node set goes down, all of the applications on that node will just become unavailable, because Dapper is in your hotpad. So using Dapper as a pod that can be auto-scaled, I think it's kind of like the sweet spot. This is currently part of the Dapper Sandbox organization. We're going to move it to the regular Dapper organization soon. Please check this out if you want to try run Dapper, not as a sidecar. We've actually had a use case come up recently from Zeiss, who have tried to run Dapper that way. Zeiss, people, if you're in the audience, thank you for your contributions. You've done great to improve this, and we will be improving this a lot more. So please try it out, give us feedback, tell us what works, what doesn't work, tell us if there is any edge cases we didn't think about. When we designed Dapper not to run as a sidecar, that would be awesome. So thank you. Dapper workflows. Dapper workflows is a great way to basically run stateful orchestrations of business processes. How many of you are aware of temporal, for example? Raise your hand. All right. I would have expected more, but now I need to explain temporal to you. Do you see what you've done? So basically, you have two ways to run workflows, right? You have declarative workflows like Argo, CD, who's aware of Argo. Many more. Okay. Yeah. This is the same CF audience. I'm forgetting where I am. So Argo workflows will allow you to orchestrate processes between containers, but there is also another way to run workflows, and that is workflows as code. So think about your code doing something like this. You might have a, it's kind of annoying. I can't see the thing here, but I'll stand right here. Think about you have an activity, and that is a piece of code that gets a message from a message bus. And then that thing needs to now create an activity where it gets a secret. And after the secret, you need to wait for some external event, which might be a human pressing a button on some console somewhere. And after that, you want to kick off in parallel to other activities to do different kinds of things. One of them needs to reach out to an external API. Well, the other needs to store that event data in a database, and you need to wait on that. You need to change those tasks together. And once that's done, you basically need to aggregate all of that data and publish it so that someone can consume the raw result. And then you arrive at the end. So any one of these steps can fail, right? And then what you do, do you know where you failed during the process? How do you recover that state? So dapper and other workflows as code execution engines will actually make sure that this entire workflow process is orchestrated, meaning it will replay, it will know where it failed, it will keep the workflow state, and it will kick everything off. This is incredibly hard to write. If you need to write a workflow engine that's generic and that can support all of these different types of integrations and activities, you're going to be managing your own infrastructure for a very long time. That's going to become very costly. With dapper, you can really do this in 50 lines of code, maybe even less if you have less activities. We do support and I will just go back here. We do support go C sharp Java Python and JavaScript. We're adding more and more languages. This is going to become stable this year. So for those of you who are looking at dapper workflows now and other many, it's going to become stable in 115. No promises, but this is the intention. And yeah, this is a really, really great API. This API specifically, you don't have to bring any external dependency for except for where to store your state. And it's built on dapper actors. How many of you are aware of the actors program model? Okay. Awesome. So for those of you who are not aware of what it is, actors are a way to encapsulate compute and stay together. Think about how Kubernetes has, you know, hundreds of thousands of containers running inside of it. An actor represents a domain business logic that you have. Let's say that you want to count cats and dogs. You might have a cat actor and a dog actor and these have IDs or names. So you could be creating millions of those instances throughout your cluster and the access to a given actor will be single threaded. So developers don't have to think about threading or multi threading at all. And so if any of these actors fail, they will be restarted someplace else in the cluster with our state. And you can arrive at really large scale architectures we know of really large companies that run four million actors in a single cluster actually dapper can host 10,000 different actors in a single pod. So you can get to very high scale, but you also need to know what you're doing because you can shoot yourself in the leg. It's a very low level program model and it's used by actors. So today for coming into dapper, I would encourage you to look at workflows before you look into actors. If you have like a very advanced use case, you can look at actors. Actors scale really, really well, but they have an issue with reminders, at least with dapper. We support, I think, up to 60, 70% requests per second when firing something called an actor reminder that is meant to basically, you know, tell an application, Hey, I want to be reminded to do something at some point in time. And that has several limitations. And we really need to make that thing a lot more scalable before we can make workflows stable. So we've basically re architected the entire thing. And this is what's coming up. We've rewritten the actor reminder service to basically add a new scheduler service. So the dapper control plane, as I've shown it earlier, it has four system pods we're going to add a new one. So you're gonna have a fifth one called scheduler that you see, you know, in your Kubernetes cluster. And those different modules or containers have at CD embedded inside of them. And we're basically using at CD as the means and as a way to list reminders, save reminders and scale them. So when we looked at a mechanism to save the actor reminders, we were pretty baffled about, you know, what's the storage of choice and storage that we can make. And a lot of you know, at CD because it's used as the backing system for Kubernetes resources, of course, but at CD is much more than that. And we've looked at CD and we're like, Okay, it allows us to select queries and do range queries. And it has full tolerance and we can trim logs. And so we've run it in a few performance tests. And we've found that the API surface it gives us with the performance characteristics really allow us to pick and to pick it as the backing system for the scheduled reminders. And this is going to come up. But you as a user are not going to have to do anything with that CD. Okay, you're not even going to know that it's installed in your cluster, you're not going to need to bring in that CD, you're not going to need to manage it with helm, nothing like that. This is because that CD is written in Go. The app was written in Go. And so it's very easy for us to just put it in the binary and use it directly. From a user perspective, it's an implementation detail. It's nothing more than a way for us to orchestrate reminders at very high scale, which means that you're not even even get reduced ops, you're going to get no ops with it. It's just going to be a control plane pod that's going to manage at CD for you on your behalf. So this is really easy because it introduces no overhead for the user and it's very scalable. And this is going to probably improve Dapper Actory Minders by 100x at a minimum. So we are very excited about this because this is going to be the basis for many things that are going to be coming into Dapper.  We're going to talk about that in a second. You're basically going to call into an API. That Dapper Sidecar creates a persistent connection to these scheduler instances and the scheduled instances will basically partition the reminders. They will know exactly which Dapper Sidecar called it to know to which application instance it needs to call back. And this is how it works. It's a very simple but yet highly efficient architecture that we're testing out. And this is going to make workflow stable and also really improve Actory Minders. If you're using Actory Minders today and you're suffering the limitations that come with the performing characteristics of it, this is all probably going to go away. Okay, so yes, we are also introducing with this new scheduler service in 114, a distributed Chrome API because workflows are great. Actors are very low level. They enable you to do incredible things. But sometimes you just need a very high throughput Chrome API. And you don't want to have to write your code to do workflows. You don't have to deal with activities. You just want to tell something, hey, I have this piece of data and I want to get reminded at some point that I need to do something. And if my application crashes, I still want it to arrive at my endpoint when it comes back up. And if Dapper crashes, I want to be stateful. And so we're coming out with this Chrome API. And you will be able to just issue a very simple HTTP or JRPC call. We will schedule the call. We will save your state. And it's going to improve, as I said, the performance for workflows and actors pretty significantly. And this is coming in Dapper 114, which is going to be released around June, June-ish. Yes. Again, no promises. It's difficult. Help us release Dapper. Yes. So one other really interesting thing that we've heard from the community was wanting the ability to publish a message through Dapper Pub Sub. It's one of our highly used APIs in Dapper. It's probably that service location in state. And so you will be able to talk to Kafka, AWS, SQS, any of the Dapper supported message brokers. And you will be able to tell Dapper, hey, publish a message to this topic in five days and three hours for now or in a year. And Dapper will basically schedule the message. And this is going to be built on the same actor reminder service that I talked about earlier. This is going to be really important for people who need to schedule jobs for the future and who want to publish it, but don't want to have to go through the CRON API to get the reminder and then schedule a separate PubSub call. So we're going to use this new actor reminder or reminder system that we're planning for many other things, for many other scheduling purposes. It's going to be used for PubSub, for actor reminders, for workflows. And if you have an idea about other scheduling features that you might want or need, then please let us know. Open up an issue on GitHub. This is the meta argument for the day. If you have any feature you want from Dapper, please open it on GitHub or let us know. Okay. So, yes, now we're going to talk about application level security. I'm going to hand it over to Josh. We're also doing a lot of work in Dapper 114 for Zero Trust. As we said, it's really important for us to make sure that everything is secure. Josh, as a maintainer of SIRT manager, will now walk you through what we're going to do. Yeah, cool. Thank you, Jury. Hi, everyone. Again, I'm a core maintainer of Dapper and work with Diogrid. Yes, so to kind of talk about a bit about what we're going to do for 2024, some things we're going to do around the kind of security space. First, we want to talk about a little bit how Dapper secures its network and the cluster. So Dapper fundamentally uses MTLS everywhere and certainly by default. And the way that we do that is through Spiffy to represent identity. So Spiffy is another CNCF project, and that's a framework for representing identities. It's very flexible, and it allows you to represent workload entity machine identities in kind of hopefully human readable formats. And we'll talk a bit about that in a second. The important thing to know here is that, yes, we have all these side cars running everywhere. We have a control plane service called Century, which is responsible for signing these workflow certificates and keeping them renewed so that side cars can communicate with the schedule service or other side cars in the cluster. And it does that through cryptographic attestation, which is a very fancy way of saying that it's going to grab a token from the Kubernetes API server representing its pod identity. It's going to send that to Century. Century is going to find out what application identity it has by looking up through the Kubernetes API server and then sign a workload identity based on that app identity. And the end result of this is, is that all of the DAPA services inside the cluster have their application identity assigned to them, a human readable, you know, sock shop or, you know, airline XYZ as part of their cryptographic attestation identity document. So some things that we want to do for 2024. So we have this XY9 certificate. XY9 certificates are great. Why? Because they use asymmetric cryptography. That's again another fancy way of saying that we don't send any secrets over the wire. You can compare XY9, for example, to something like JWT or, you know, A-O-I-D-C, whatever you want to call it. The problem with these things is that they are fundamentally they are passwords and you're sending passwords over the network.  They are fundamentally passwords. So the nice thing about XY9 happens at the TLS layer and yeah, it's asymmetric cryptography. You can't steal a private key unless you really do the kit, but they don't get sent over the wire. So we have all these identity documents, XY9, and they represent, again, the application identity. A neat thing you can do with this is just like we do M-T-L-S between the services in our DAPR cluster. We can also, in coming this year, implement them to actually talk to our external components as well. So A-O-S is a really good example for this. They have great support for accepting XY9 certificates in their kind of roles anywhere feature. So you can describe IAM roles in terms of incoming TLS connections based on that spiffy ID. So work in progress, not done yet, but the kind of component manifest that it will look like is something like on the left. And you notice there that typically if you're going to, or always, hopefully if you're going to write a component manifest in DAPR today, you're going to have some kind of connection string, hopefully a secret reference that's stored somewhere. But instead, with this feature, you'd be able to say, actually, I just want to use spiffy off. Literally no secrets involved. You're using the identity of the pod itself. And I'm going to then connect to AWS using that identity. And so on the AWS side, I can then highlight. If you go to the, yes, look here on the AWS side, I can just say, actually, my blue namespace, my DAPR application has access to this S3 bucket. And that's super powerful. Because what that means is you're describing your authorization roles, not in terms of some abstract, you know, infrastructure with, you know, crazy URIs or anything like this, we're actually describing the authorization to, you know, infrastructure resources in terms of applications. Why this is so good is that it gives, it empowers application developers to have the freedom to describe their applications in human ways, like they want to describe it in things that they do, but it allows the security teams to still be able to control what they have access to. But they're both happy because the security teams can actually read the roles that they're writing and understand, you know, what is connected to what in a human and readable way. Here's another example on the side, a bit more complicated. I'm not an I am or AWS wizard, but you can start to hopefully appreciate that you can start to design these very descriptive roles in a human readable way, you know, wildcards and things like this, namespacing. And again, this is really powerful to give developer look, here's your namespace, you know, go ahead, use DAPR, use the APIs you need to, and as a security team or a platform team or what have you, are able to actually, you know, still keep the kind of keys to the castle and make sure they're kind of reading and writing to the right things. You know, a lot of security instance, especially when it comes to authorization, typically come from misconfiguration, copy and paste errors and things like this. When you start talking in human readable language, you eliminate a lot of these problems. Moving on, the next thing I wanted to touch on, so briefly, roots of trust, probably do a whole talk on roots of trust, but very briefly, roots of trust, this is the certificate authority. So again, in the x y by nine space, you have a certificate authority, which is some kind of self science certificate, which is the root certificate that is used to sign intermediates and then and or leaf certificates. And they're the things that actually have the identity. But when you make a TLS connection to a server, you have to pre trust the root of trust in order to verify the certificate, like the equivalent would be when you buy a laptop, it comes pre installed with a bunch of CAs. So when you go to Google.com, you know that Google.com is signed by a root of trust that you already trust. Yeah. So in JAPA, we, yeah, we distribute this route of trust across the cluster. This is, you know, public data. That's fine. But the where the problem comes in, is where DAPA today will self sign a root certificate and store it in a Kubernetes secret over here. So essential come up, we'll check whether it exists or not. And if it doesn't, it's going to generate that root certificate. That's fine. However, it can be problematic for two reasons. So number one, Kubernetes secrets in general terms are quite problematic. So ideally should never be using Kubernetes secrets will stop. They're discoverable from the API. They're stored in net CD. If you get an net CD dump, then you go keys to the castle. Again, they could be encrypted at rest or what have you. But yeah, they discoverable through the API. And so they're not always great. The other thing is that actually you might want to integrate your root PKI with your existing systems, especially for large organizations who have a dedicated PKI team. They want to have this observability and they want to incorporate all of the workflows that have been across their infrastructure under the same PKI system. So to alleviate this, we're going to add support for external CAs. So all the major cloud providers all have certificate services. So GCP AWS Azure, but also to have support for vaults. That's another kind of certificate issuer and set manager costs bias, but I'm happy to have that one included as well. And the idea here is that the century service will instead of self generating a root CA and again, storing a Kubernetes secret. That's bad. We're going to be requesting an intermediate secret intermediate certificate for one of these services. And what does that give us? We're no longer storing private keys at rest. And particularly that issuer certificate issuing certificate, which is the really painful one to be storing, storing at rest and making available through the API. We're keeping everything from memory, which is super important, keeps everything much more secure. Yeah. What else does this also give us? So again, I was mentioning there about, you know, PKI teams and security teams already having their stuff set up in their infrastructure. They've now, you know, heard of Kubernetes are being thrust upon them. And, you know, they're now having to like learn all this stuff. And, you know, the business going towards this kind of distributed Kubernetes as well. But they still want to have control of their PKI system. And, yeah, so that will enable them to have total visibility across all the clusters. And having a shared route of trust is also going to allow us to do some really cool stuff with cross cluster communication. And again, this cross cluster communication will be MTLS, strictly MTLS, between DAPA identities, DAPA services, as well as having that human readable application identity. Again, which is super important. You can start writing your policy and authorization rules based on human readable words, not some kind of crazy you IDs that the infrastructure gives you by default with service accounts and what have you. So yeah, back to you. Yeah. Okay. So if we have some time and we do, I need your help. I want to know what we should be focusing on. So I'm going to ask all of you a few questions about things that might be important to you, not DAPA related just in general. Okay. So I'm going to bring up a topic. And if it's important to you, please raise your hand. Okay. This is going to be really, really important for us because we want to know where to invest our efforts in. Okay. How many of you are interested in multi cloud architectures? Okay. Thank you. How many of you are interested in workflows as code like the ones I've shown earlier? Thank you so much. How many of you are interested in wasm? Okay. How many of you are interested in cross cluster communications where wait, wait, wait, where, where you have applications that are basically the same applications that need to operate in we're already raising your hands. They didn't finish. That's that's great. Yeah, you're taking the assignment on really well. Wait, where you have the same applications running on separate clusters in active, passive, and yes, you. Okay. Awesome. Yeah. Okay. How many of you are interested in mold in cross cluster communications where you have different businesses running in different clusters and they need to communicate because you can't have all services running in same cluster. All right. Thank you. This is great stuff. Do you have any questions, Josh? Okay. This is this is all great stuff. We're going to open it up for questions, but we will be here for 30 minutes after the session ends to talk to you face to face. So please come and say hi. And yes, if you want to step up to the mic, please go ahead. Yeah, thanks, Aaron. Thank you.


Chicks would come up to jail, start riding. I done seen chicks back in the day.  Damn, actually, dude, she got some girlfriends. Or a dude would be talking to his girl, she'd be at work, you know, working at the hospital, and they'd be like, damn, put me in the phone. Send them a little letter, because I told you there was a specialist in that. Send a little letter, a little picture.  Next thing you know, she'll ride five, six years. I'll watch you coming up there, put money on your books, doing the bills. Shit ain't going on, though. Oh, no, they done. Bitch don't ride five weeks with you.  She tell about that. We didn't have social media back then. So they had, listen, back then, the women, nobody had no lives around the way. If you had TV, you had a VCR or something.  They get little Johnny's on the hood. No, I'm not saying that, but when I... I didn't know Bobby. I'm not saying that. I wanted to get back to such and such.


parents because they brought us into the world. There are asal but the imam is asal wujud. There would be no world right now if there was no hujjah. He is the source of why we're here and there's a very important relationship with him that we're not seeing, not living.  You know how when his brothers came they didn't recognize Nabi Yusuf but Nabi Yusuf saw Benyamin and Benyamin he had things he had certain attributes that Nabi Yusuf wanted because he wanted to keep him with him. So what they did was because Nabi Yusuf wanted Benyamin to stay with him. They organized a plan where he took a cup and he planted it in the back of Benyamin and then he said wait there's a cup missing, there's something missing and all the brothers said there's no way anyone here would have stolen it. So they searched the bags and it turns out in Benyamin's bag he framed him. Nabi Yusuf made a scenario and he framed his brother that he stole the cup because he said I must take him prisoner now. He said no please don't take him prisoner. His dad's an old man. He means a lot to his dad. So Nabi Yusuf responded with the ayah. God forbid we take anyone except who we find our goods with. We'll only take those who our goods are with. So Benyamin on the cup. If I take anyone else who my goods are not with because they told him take one of us instead. He said if I take anyone else then I'm an oppressor. I cannot be an oppressor. I must take the one who took my goods, who has my goods. His mata'ana, my goods. What goods though? The cup is that really what he means. You see for every dahlah in the Quran there's a button.  He's the perfect human being in his time, the way Imam Mahdi is insane al-Qamun. Nabi Yusuf, he has all the attributes that we love. Courage, faith, he has manners, he has knowledge, he has all the mata'a. Mata'a. He says mata'a an a, an a. So he looks at Benyamin. That means Benyamin has some mata'a that Nabi Yusuf wants. He has certain attributes. Nabi Yusuf is not the cup. So he said I want to bring those mata'a here because if I take anyone else or be a person, that means anyone doesn't have the attributes that the Imam wants from us, he won't take us. He wants us to have certain attributes. Then he will take us. When he sees his mata'a, us he will take us with him. He will create a scenario, the same way Nabi Yusuf created a scenario. He will frame us. He will plant a cup in our bag and he will come to us. You don't have to worry about it. He will do it for us. He will bring us to him. We have to have those mata'a. What are they? What are those attributes that he wants? Now, there's so many but I want to remember a few and bear with me with these. Sorry that it's the final night so I'm trying to get everything out as much as I can while I still can. So those attributes, what are they? First one, very important that we all must have in this day and age, maybe the most important attribute. Basira is vision. No, be aware. Basira, don't be duped. Like for example, the Canadian Prime Minister, I was just elected Justin Trudeau, I think his name is, you know, everyone's so happy about him. Everyone's posting on Facebook. He's like, he's good with Muslims and Hijab and then just check out what he says about Israel. You know, we have Israel's back, no matter what happens with Israel. The one thing that all the Canadian parties can agree on is we back Israel. But Muslims know Basira straight away. He says some nice thing about Hijab. Oh, we love him. We saw him when I brought for pictures. Where's the Basira? How can we so easily be tricked by pretty words? Where's the Basira? Again, Basira, unity. Sunnis and Shi'as. How much must be said about that now? People are trying to conquer Islam by dividing us. People of Basira know that unity is one of the main principles that we must adhere to today. That we are one umma. That if we stick together, we won't be broken. That it's not Sunni, but it's Shi'a. That what's happening now is not that they want us to believe that so we separate and it's not that we can't let it be that Oh, our difference is with Marajah, let alone Sunni and Shi'a.  If you follow Sayyid Sadik Shirazi, that means you love Imam Hussein. If you follow Sayyid Khamenei, that means you love Imam Mehdi. Everyone has an Imam and it's like a football team. I'm against you. You're against me. I don't see who do you don't see with me. Where did that come from? There's no such thing as the Marjah for an Imam. There's no such thing as the Marjah having a team. The Marjah don't speak like this to each other. It has to be unity. Sunni Shi'a, unity between us as well. It's okay to talk to someone else, to have some healthy dialogue with someone else. Find out what he thinks. They didn't find out what you think. Have Basira or Muharram. Muharram is a time for change. It's a time for us to grow, to grow close to Imam. But then what are the questions that we will get every single day is Tabbir, Halal or Haram. Are we still there? It's tiring. Why are we growing? It's still on the same subjects year in, year out. Where's the human growth? This is so much more.  There are so many things that we have to have Basira about, personalities and politics. This day and age, the cultures, the technology, east and west, you have to have Basira or you will lose your faith. You have to be aware. Follow the news. Find out what's going on. Find out the stances of your alama. Be a free thinker. My relative, she messaged me at university that was saying Imam Khomeini is an evil man. Imam Khomeini is someone who was a tyrannical ruler. He was a massacreer. She told me, Hassan, is this true? I told her no. I don't think I've ever read about a man like Imam Khomeini before, such a pure man. And I've cried my best every single night. I've mentioned one thing from him. And you guys probably know this that because I think that if we hold on to someone like him, we won't go astray. And people, they have doubt because there's so much character, assassination, there's so much propaganda to bring us away from someone like Imam Khomeini. People don't like to talk about these things. Well, I want to talk about these things. Not at all. My advice, everyone, hang on to him as much as you can. Read from him. Or the world right now. Look at the stances in the world. Saudi Arabia. Find out about Saudi Arabia. Look to its history. You know Saudi Arabia. You know the royal family of Saudi Arabia? They're actually from the heritage of Ben-Iqin A'a. The Jewish tribe used to fight Drasul. They're from that tribe.  It's history. The family tree is there if you want to check it out. Find out about the history of Wahhabism and Takfiris. And that it's not Sunnis. And that it's not Sunnis versus Shi'as. It's Sunnis and Shi'as together. The advice is there. And don't be fooled. You see what happens right now. You see ISIS. You see Daesh. You see Takfiris.  You know, Isra'il is not that bad. It's too sad to the same point. If you say that, you're not very politically aware. Isra'il is the main enemy. The main enemy. You must always remember that. And any friend who is Isra'il, we have to disassociate from them. The main enemy. They said that what's happening there is not true as you had. And the people who die are not sure of that. If we went by what they said, and these are sheikhs in Qom, 20 years in Qom, 30 years in Qom, saying this, not any normal sheikh has much knowledge. And he's saying this, you know what's happening right now. It's not true as you had. Not for good. And that if we were to follow what they said, then say that they would have been demolished. Thankfully, the men of God were there. They protected it. But they were given permission to buy our great Marajah. So Marajah, they acted fast. We have to have Basira to see who are the true scholars. You are the non-true scholars. It's 100%. He said at that time, he acted very fast. He said that every single drop of blood in Syria is on my neck on the day of judgment. Go, Basira to see. They're going to follow this one. Five years later, it shows the importance of what happened and the fast action showed. But before then, everyone's like, how could they do this? Oppression? Helping the oppressor? No, Basira. Basira, very important for us to follow.


Working from home is an incredible blessing but it's not always roses and cups of tea. There's a lot of pitfalls to avoid when you're working from home and we're going to talk about those today. Where we talk about productivity tips for work from home sales professionals and hotel sales professionals. I've spent a lot of time talking about all the benefits of working from home but keep in mind there's a lot of pitfalls to avoid as well. There are things that will work from home environment enable that aren't the healthiest of habits and we're going to talk about some of those habits today. One pitfall to avoid when you're working from home gaining weight. With the refrigerator just steps away it's really easy to just adopt this eat all day philosophy where food is always available you don't have to go far to get it and you quickly start to put on those pounds. Now I've probably gained pounds over the last 10 years I can't tell if it's from working from home or if it's because I'm getting older but certainly I weigh a lot more now than I did 10 years ago and working from home is probably a result of that. So there's a few things you can do to mitigate gaining a ton of weight when you start working from home. Strategy number one is healthier grocery shopping so if you're going to go to the fridge let's make sure the fridge is stocked with healthy options making sure that your pantry has some high protein options and not just potato chips and crackers. Strategy number two exercise now that you're working from home and you have some more flexible time to devote to your exercise program now we need to put it in motion so no more excuses let's build in some time to exercise and curb some of those calories that we've consumed. Another pitfall to avoid when you're working from home is doing your household chores. It's so easy to just throw a load of laundry in or run the dishwasher and do a set of dishes and those are all great things about working from home is the flexibility to incorporate those into your break time and your lunch break time but if those things become consuming they do take time and now all of a sudden some of your most productive time and your most alert time is spent tending to chores instead of spent on strategic projects and things that are moving projects forward. So if you're going to do chores from home make sure that it does coincide with some times of the day where you are feeling a little bit down and you don't have as much energy to devote to some strategic items and maybe work it into your break time as well or save it for when the work day has ended and into the evening hours. Pitfall number three is the corporate ladder. Now this won't apply for all of you out there in fact working from home doesn't impede you from climbing the corporate ladder at all but some organizations like to have that face-to-face time with employees and if that's important in your organization we don't want working from home to impede you from reaching your goals. So take a look at your own organization's culture and see if working from home is actually holding you back from achieving the next step in your career. Pitfall number four isolation. Now I did a blog post on how to network with people when you work from home and you can find that above here. The reason I did that post is because isolation is a real thing when you're working from home. You can quite easily fall into the trap of being by yourself and alone for days on end with literally no human interaction unless you have kids running in and out of the house. So we want to make sure that you're still connecting with adults and having intelligent conversations. So when you're finding that you have been at home for a while and you're not getting out and having those intelligent conversations find some different ways to network with people and connect with people and decrease that feeling of isolation that might be creeping up. Pitfall number five is lack of support from a support system. When you're working in an organization chances are you have a technology support team even a human resources department an accounting department. When you're working from home especially if you're an entrepreneur some of those resources have now disappeared. You cannot go down the hall and just tap on Joe's door when your printer breaks down. It's all on you because you're in your home office. So there's a few things that you can incorporate as strategies when you do need support from people outside of your skill set. For tech support places like Geek Squad out of Best Buy they're a great resource to tap into when you're working from home. You might even have a skilled neighbor or friend or spouse that can help you out. But the Geek Squad is a great place to fall back on if you don't have that support system in your neighborhood. For admin support nowadays there are tons of virtual assistants out there that you can pay to do some of that administrative work. You'll likely find these best through LinkedIn or even through Google and they don't actually have to be in your neighborhood unless you want someone to meet with face to face.  So take a look into virtual assistants as an option to kind of offload some of those more administrative tasks so you can focus on the more strategic things at hand. Pitfall number six, flexibility leading to unproductivity. This tends to happen a lot to people who just start working from home and they love this flexible lifestyle that they're able to do whatever they want whenever they want. That's all good and great but you still have some work to do. So don't let flexibility get in the way of you completing your strategic work. You can still go to the gym and fit in that workout. You can still do that load of laundry but try to go back to the reasons you wanted to work from home to begin with and make sure that all of that flexibility doesn't lead you down a path of being unproductive all the time. Pitfall number eight, loss of boundaries. Boundaries can look one of two different ways. It can be a physical boundary where perhaps your workspace is now intermingled in the home and you can't separate the two spaces and so now your home has just become an office space and it no longer feels like a home. I can speak to that one. The last house that we lived in as a family, my home office was kind of sort of in the middle of the house and it actually wasn't until we moved to this house that I realized what was actually going on and this feeling of stress was permeating throughout the home and I felt constantly on edge and constantly stressed out from my job. Well it wasn't my job that was stressing me out. It was actually the location of my office and again I didn't realize it until I had moved into this home here where my office is now above the garage kind of away from the main living area, definitely away from the bedroom area and I'm still working just as hard if not harder in this new home but I have so much less stress because I've created a separation between my office space and my living space. So that's one way that you might be losing boundaries in your home is if your office space or your desk space is almost too integrated with your home space and there isn't enough boundary there. Now the second way you can lose boundaries is with the people in your life themselves. So that's when family members and friends catch wind that you're working from home and now you have all of this time to spend with them and all of this time to pick up their kids from school because hey you work from home you're flexible but without setting boundaries with those people those things are going to happen and again you're going to lose strategic time spent on your projects. So you need to set physical boundaries at home with your office space but you also need to set boundaries with your friends and family so that they are aware of what your goals are and then you are actually working when you're working from home. These are some of the pitfalls to avoid when you're working from home but remember there's so many great reasons to work from home as well that it's really a balance of the two and finding the right balance for you is what you're going to do probably in the first six months to a year of working from home. If you have any questions on how to work from home successfully please comment below this video I'd love to reach out to you and let you know what I do to create a productive environment in my home and please go to productivitypantry.com to get more productivity tips as well as sales tips if you're in a sales profession. Thanks for watching and we'll see you next time. Bye for now.