Welcome to the final recitation. And we're going to do the final exam review. So it's going to be mostly similar to the midterm exam review, but customized for the final exam. So again, we're going to go over the location, day, time, and then the final exam material, format, and tips. We will also review last year's exam, I believe, after we're done with the slides. So final exam will be next Monday, May 15, from 3.30 to 6.30. So three hours exam. The location will be the same as lecture room. But please double check in your MIHAB. And also keep an eye on the discourse forum for exam announcements. The procedure will be similar to the midterm. There will be seating charts. And it will be almost similar to the midterm procedure. So final exam material, I've divided that into midterm topics. We have post-midterm topics. And then we also have papers and some additional topics that you've discussed in the class. So going, again, quickly over the midterm topics that you covered, so starting with the process abstraction. And you learn that process, organize information about other abstractions. And it is not tied to a hardware component. We use process abstraction to separate policy, the what, from mechanism, the how. And why do we use abstraction is to just like hide undesirable properties, provide or add new features and organize information. You also should now have a clear view that the threads abstract CPU, address space abstract, the memory, and the files abstract the disks. We've also presented you with the process model that a process could have one or more threads. It also has address space and a file table that is private to it. We've also said that there is a file handle or file system that's divided into three levels. You have the file table that is private to the process. And it has references to the file handles. File handles are also private to process. But once you start working, it will be shared between the parent and child. And then you have the file objects that are shared system-wide. And file handles have a reference to the file objects and file objects mapped to blocks on disk. We've also presented you with process calls. You should have now a good after completing the programming assignment. You should have a good idea what each of these process and process calls does. Also, we then discussed synchronization. And you should by now know what is a critical section. Why do we need to protect a critical section and how do we protect it? So you've been presented with various and also implemented various synchronization primitives, sleep locks, condition variables, read the writer locks. So you should have a good understanding of these, how to implement them. You should also have an idea of deadlocks, starvation, race conditions, what are the definition of each one of these and the differences. How should you avoid them? Also, you should have a good idea about some synchronization problems in case you're being asked about them. So you won't waste time just figuring out what is that problem. Then we moved into the interrupt and exception handling. So for interrupt exception handling, you should know the types of interrupts. And you should know how to differentiate between an interrupt and an exception. How should we handle an interrupt? And you've also discussed the context switching. You should have a good idea of the process of context switch. For scheduling, you should know why we need scheduling, which is we need it for multiplex and CPU. And you should have a good idea of the thread states and the transition from one state to another. What does it mean? Also, you should have a good idea about scheduling algorithms, round robin, MLFQ, RSDL. You should be able to compare them, improve them, talk about advantages, disadvantages of each one of them. Then we've moved into the memory management, and that's where we discuss the virtual and physical addresses. So you should know the process of translating virtual to physical addresses. How we divide up the virtual address? How we do retrieve the physical address for a given virtual address? What is a page table? What is a core map? What does the core map keep tracks of? What does the page table keeps a track of? Why do we need them? Also, the different implementation that we've discussed for page tables, flat array, link list, multi-level arrays, you should know how are these implemented and advantages, disadvantages of each one of them. Also, then we moved into the TLB. We've said that TLB is used by the MMU at its part of the CPU to speed up the virtual to physical address translation. Also, memory faults, page fault, TLB fault, the difference between each one of them and which one triggers the other. So TLB fault doesn't necessarily trigger a page fault, but a page fault must be preceded by a TLB fault. Then we discussed swapping. Also, we've discussed some algorithms on how we can choose the page that we need to elect or swap out. So you should have a good idea of these algorithms and advantages, disadvantages of each. This is the midterm topics that we covered. Then we moved into post-midterm topics. We discussed disks. So you should know what is an HDD, SSD, the pros and cons for each one of them. The parts of the HDD, you should know these parts, advantages, disadvantages of each one of them. Then we moved into files. What is a file? What do we expect from a file and file structure? You should have an idea of all of this. For example, where should we store? How should we store the metadata about a file? So you have different ways for that. You should know all of these ways, advantages, disadvantages. You should be able to compare them, improve them. File systems, then we moved into the file systems. So you should know the expectation of a file system. Why do we need a file system? What are the design goals for a file system? And what are the data structures that are presented? So we presented several data structures to organize data blocks. You should know these algorithms and should be able to compare them. Caching, consistency, caching and consistency. We've discussed buffer cache. We should know what is a buffer cache. And where should we put buffer cache and why? There are several scenarios for that. So you should be able to compare each one of them. And then we moved into discussing journaling file systems. So you should know what does a journaling mean? And how does a journaling file system works? And different scenarios when there is a crash and how does it recover? We've also discussed the Berkeley FAST file system and also log-structured file system. So for each of these, you should have an idea how does it work and advantages, disadvantages. And several other topics, subtopics that are, I couldn't cover everything here, but you should go over these slides since the final exam is cumulative. So everything discussed from day one up until the last day of classes is included in the final. So then we also presented you with some papers and some additional topics. So for the rate paper, you should have a good understanding what is rate different kinds, different types of rate, and you should be able to compare them. Then we moved into discussing virtualization, full virtualization, per virtualization, container virtualization. So again, all of these you should have a good idea about and you should be able to compare them. So to what extent you should know? To the extent that's being discussed in the class. Then we moved into performance and benchmarking. Also we've discussed under slow and then the paper hence for computer system design. So these are the topics that we covered throughout the semester. There are some stuff that you really shouldn't miss. For example, page table translation, questions about page table, how to translate addresses. You should know if this comes into the exam, you should know how to do that. You shouldn't really lose point on these such questions. Rate types, make sure you don't miss these. Also, hints for computer system design. Make sure you understand and know a couple of them. You should be able to compare them and discuss them. So these are some stuff that you shouldn't, for example. And also the HDD parts, the disk parts, don't miss out on these stuff. A question comes with a figure. We did have a question comes that in previous exams with a figure of the disk. And asking you about parts of the disk. So you shouldn't really miss points on such questions. So any questions on the material covered throughout the semester? OK. Call any points, anything? Well, I guess we covered a lot of the material. What I'm trying to do is kind of also bounce through some of those bullet points we were talking about. So possibly we'll just go back to the other one on this. Yeah, like one or three. Oh, OK. Obviously, this is an incomplete list on this, as Ali said on this. You probably hear this back some of the time. Oh, call. Sorry. A few people are hearing, but the people out in video land are not hearing on this. So as I was just mentioning on this, Ali's list up there is, as he had mentioned, it doesn't cover every last tail on this. But what I would say is in terms of exam preparation, obviously you want to make sure that you are familiar with the specifics. Those are going to show up in some of the short answer questions on this. I would expect that the short answer questions are going to, as with the essays, disproportionately wait the last part of the course. But again, everything from January on is fair game on this. In terms of what is on the short answer questions, I don't want to say it's a no-order-you-don't, but it's the sort of thing like what Ali was saying, like keep track of. You don't want to make sure a virtual address is not the same thing as a physical address, yada, yada, on that. Besides that, a couple comments with respect to the essay questions. I assume that Jeff is going to be addressing this in much more detail in tomorrow's wrap-up class. But he is fond of designing at least one or two of the, especially like the 25-point questions, to try to cover lots of topics all at once on this. Like if you look at last year's exam, which we'll be paging through as an example in a couple minutes, there was one question, the 20-point question, which was kind of on one specific area, obviously virtualization. But then the other two questions really did cut a wide swath across the entire course. And that's something that he's actually going to be expecting. So it's not like, well, what should I study? Should I study? Maybe scheduling, because is there going to be an essay question on scheduling? There conceivably could be. I'm just saying if you look at the format of these essay questions in the past, it's probably going to be an essay question that will involve scheduling, but it will also involve other subsystems, too. So you need to kind of know how the subsystems interplay on this. So if this makes sense, it's not going to be like one particular question on this or that or what have you, it's going to be a combination of them at all. So I was going to kind of dive into, again, last year's exam on this, but before we go on, possible questions about, like in particular, some of the lessons that I had covered on this, but in terms of like, who knows, processes, synchronization, well, who knows. Interrupts, remember the kernel, everything begins with an interrupt on that. We talked about you people designed a process subsystem and kind of had an inter, if you will, tie in with a threading subsystem. Again, you should have a good idea on what's the difference between a thread and a process on that. In terms of scheduling, scheduling, again, Ali had mentioned the various types of schedulers on here. I would be, remember, take a clue from the midterm in terms of how Jeff asked this, that yes, you need to be familiar with a particular type of scheduler, but then, well, maybe go a little bit beyond that. What's a weakness in the scheduler and how can we possibly address that weakness? That's more going to be what the grading staff is going to be looking for. In terms of paging, swapping, the whole, like memory management system, questions about that, anything else on this? Going once, going twice, sold to the person, what have you, and then maybe next one. Discs, in terms, disks, files, again, this is post midterm on this, we know the metadata in terms of where does everything start. Remember, there's going to be the anchor block and then you've got these inodes and then there's obviously different ways of skinning the cat on this. What we're trying to do is remember the genesis of file systems is to provide persistent storage on this, but we're also dealing with legacy mechanical hardware. So that's where a lot of these design decisions came in in terms of remember, we try to scatter the inodes throughout the disk in strategic locations. If at all possible, we're trying to minimize our movement on this in terms of, let's say, where do we store data on this? Well, we've got the data data, we've got the metadata, and how much metadata do we actually store? And there's other things, remember, Jeff, I know he talks about in terms of like, there's typically levels of inodes on this. So in other words, depending upon how big the file is, if we have a really small file that's only 50 bytes, maybe just have one reference to it and done on this, as opposed to a really big file, it's probably gonna have several layers to the tree on this and don't create them unless you actually have to have them. And then, I would say perhaps a good essay type question might be to compare and contrast something like the log file system with a standard UNIX type file system. In other words, why have inodes in the first place as opposed to remember Jeff's lecture in terms of with log file system, we're just gonna kind of write everything sequentially and then we've got to trade off with the cleaning process and there's pros and cons on this. So it's not simply a discussion of one file system, but well, and then you might ask you under what type of use scenarios would something like log file systems be better as opposed to let's say a more traditional file system involving inodes and well, not log in. When I say logging, let me be clear, we're not talking about journaling in the sense of safety on this. Everyone clear on that distinction logging first in terms of the log file system as opposed to journaling, which is a type of logging on this. In terms of when we're talking about like journaling, what we're talking about is essentially safety of the file system itself in the case of a power cut or other types of corruption on this. So, and then I think that should be about it. And then as Ali had mentioned, like the research papers too. And that's another thing. If you look at previous exams, I would say dollars to donuts, at least one of the essay questions is going to involve one of the published papers on this. And even something like the virtualization question last year, which you're thinking, well, wait a minute, we just talked about that in class as well. In order really to understand the third component to virtualization, which is the per virtualization, it was actually buried in the discussion about how can you virtualize on a smartphone? So that's actually where the discussion of per virtualization took place. So I would say, certainly at some level, you wanna make sure that you have a handle on the research papers that were discussed. I would say there's a better than even chance that something's gonna show up from that, just knowing history on this. So, questions, comments? Absolutely nothing. Well, what we were gonna plan to do is kind of wrap things up, kind of take a quick peek through last year's exam in terms of what you would have taken, again, one year ago, essentially at this time May 9th, but 2016 instead of 2017, and how could you actually approach this? Again, like we had mentioned from the lecture that I had covered yesterday, it's the midterm, in other words, 10 multiple choice questions, plus a bunch of short answer questions, plus an essay, a 20 point essay, but Jeff's also gonna throw on there two 25 point essays. Oh, did I jump ahead on that? Yeah, sorry about that, yeah. Exactly on this, so that's, yes, okay. So, and like I had mentioned, I don't think that time is gonna be the issue like it was for the midterm. I would just encourage everyone here and everyone again in video land, please do take advantage of that extra time. I know you wanna get out, just kind of cut and run for the summer, but again, this is where the majority of the points can be garnered and it is typically, certainly for this year's midterm and previous year's classes, what separates the sheep from the goats, so to speak, that the essays, they require a little bit of thought and planning and spilling of ink too. So just don't rush into writing them and don't rush getting through them on that because again, that's where you'll typically see the greatest disparity in terms of scores. I would say in terms of where you can actually save time and effort, it's gonna be the short answer questions. I would say, I don't know if you wanna chime in on this, but the short answer questions from my experience, people actually tend to write too much to the extent that people miss points on the short answer question. It really doesn't matter how much they write if I can almost tell from reading like the first sentence, sentence and a half or so, whether or not this person is going to get pretty much all credit or is halfway off the boat or is completely out to see on this. So the short answer questions really may be a few sentences at most. If you find yourself filling up a half a page, that really is too much on this. That's something that you can save time and get through very quickly on this. And then in terms of the essays though, again, that's something, it's not even so much the length, but the fact that you really do need to think through and plan what's going on. So let's take a look at, okay, I'm pulling up the final exam for last year. Oh, oh, sorry, okay. Yeah, I'm coming, yeah. You want to? Yeah, yeah. All right, you want me to jump in again? That was okay. So let's move into the final exam format. And this is based on last year's exam. So you're gonna have again something similar to the midterm in addition to two long answer questions. So the total points gonna be out of 100 points. And you're gonna have 10 multiple choice questions that worth one point each. And these are drawn directly from the second half lecture slides. And it should be easy. So all these information, you can find it from the first page of the last year final exam. So then you're gonna have six short answer questions. We will give you credit for the best four and each one fourth worth five points for a total of 20 points. And please answer them in four or five sentences. Shouldn't take longer than that. And these are mostly drawn from second half material, but not entirely. So some of them could cover the first, the midterm topics. Then you're gonna have one medium answer question. This is equivalent to the long answer question in the midterm. This is worth of 20 points. And it's drawn from the second half material. And you should answer it in a page or two. And then you're gonna have two long answer questions that are really long. So each one worth 25 points for a total of 50 points. Both of them are required. It's not like the midterm where you need to choose one. So please answer both of them. And they integrate material from the entire semester. And your answer should expand to several pages, two or more. So 10 multiple choices, short answer questions, and then one medium answer question, and then two long answer questions. All are required. You're gonna have three hours. You shouldn't have problems with the time. So it's not like the midterm, 50 minutes. So use your time wisely. As for tips, how should you prepare? Again, study the lecture slides. Then link that to what you learned in your programming assignments and your station material. Then start solving previous exams. Once you do that, you should be fine. How to answer? Please write your answer clearly. If you wanna maximize the number of points that you get, make sure we do understand. We can read your handwriting and we can understand what you're answering. So as much that we better understand your answer, you can maximize the number of points that you get. So draw figures, diagrams if they help, be concise and be organized. Use bullets if needed. How to allocate your time? Again, the points assigned to every question should tell you how much time you need. So long answer question, 25 points. So that means 25 minutes around half an hour. For long and for medium and long answer questions, know what is being asked. Please read the question completely. When we graded the midterm, so that many students didn't really read the question. For example, the question that asked you for the kernel privileges for multiplexing memory, many students didn't read that what we need is the special privileges that the kernel need for memory multiplexing and not the general kernel privileges. If also for the long answer question that was asking about predicting the wait times, many students just like they discussed some other wait times other than the one that were clearly asking the question that is when a thread is put to the waiting queue. So please read the answer two times at least. Read it completely. You do have time. Then start answering and link it to what you've learned throughout the semester. So that should be all for me. So you can, if you have any tips and you can start with me. It's last year's exam. So the 2016. Yep. I'm just gonna jump right into the short answer questions on this. Again, just a few minutes bang through the multiple choice. Just make sure that you haven't made a dumb mistake on those. And the other thing I can suggest too is you're going to have ample time probably to do all of the short answer questions on this. I know probably the majority of people did more than what was required on the midterm, but for the final, there really is no good reason for you're not taking a whack at all of them. And then you will have enough time to go by back and with a clear head decide, well, which of these is actually gonna be the ones that you wanna submit for grading on this. Actually, you know what? We pick the highest. So that is correct. So you know what? You don't even have to select. So just write down something for all of them. It does not hurt you on this because I'm gonna assume that time should not be an issue on this. So we begin with the first short answer question here, which is question number two and we're talking about RAID here. And remember, recall that RAID level one, we've got an array here. And remember what RAID one is? That's the mirroring thing. We've got two disks that essentially are duplicating each other. And well, so obviously you wanna make sure what's the difference between RAID one, RAID zero and these exotic things like RAID five, RAID six on this. So we're gonna start off with something like this. And it's not so much that Jeff wants you to regurgitate what it is, but well, why is it that he dives a little bit deeper? Why is there a asynchronous performance to be expected from RAID one? I'm thinking, hey, wait a minute. RAID one is not the one that we typically pick for performance. That is true, it's RAID zero on here. But what he's looking for is, do you know the fact that RAID one, we've got two disks that contain duplicate information here. So why can we expect to see a jump in RAID performance on this? Think about it like this. Since we have two completely duplicate copies of this, we can kind of mimic RAID zero in terms of reading on this. In other words, read a block from one disk and a block from another disk kind of almost at the same time. We can also take advantage of the fact that we have two different disks with two different disk arms. So in terms of where that file is, we can kind of look ahead and see, well, maybe optimize it. So we've got, when it comes to reading, the best of both worlds. We have two complete copies and we can kind of pick, well, interleave it to speed up the reading process. Obviously, that's not gonna be the case in terms of writing, so that's why we see this performance disparity in terms of writing. So that kind of would be the sort of thing that we would expect for you to kind of put down for this. So questions, RAID, what kind of makes sense? Okay, moving right along. Question number three, and look at that here. The performance hits paper that we talked about yesterday. In this case, it's showing up on a short answer question on here.  Well, that we talked about either yesterday, or again, if you took a look through the paper, you can kind of pick beyond that. So what are some of the hints that we can actually talk about? Well, Jeff has some listed that are there, but again, you can go beyond that. Well, we're talking about, like remember separating the normal and the worst case on this. We spent a little bit of time discussing that yesterday. And then just beyond that, we also want, watch it. Read the question here. It's one point per hit. And then he's also looking for one point per explanation on this. So in terms of we can get six points kind of maxed out at five points on this. But you can keep going on this. So we might take an example of what is an example of, let's say separating out normal and worst case on this. I got this from yesterday. I gave one specific visa V assignment three. But again, feel free to create an example that you might. I'm talking about swapping. I'm sorry, like the TLB shoot down. And remember the fact that in many cases, most cases you really don't have to do a TLB shoot down on this. So optimize your code pass that in most cases you don't have to deal with that and then separate out the worst case that that's going to just take some time. Plan to throw one away. And again, you could even say, how about an example of that is, well, my original design for assignment three or what have you, but not to be cynical on this. What he's trying to say is, don't worry about starting over completely over because very often you need to kind of let ideas percolate in your brain before you can come up with a workable idea on this brute force, do things well, complete in background, certainly background. That's not something that you had to do yourself in terms of programming, but let's say in a user operating system you could spin off a worker thread. Or actually, you know what? If you were towing around with, let's say, kicking off a paging daemon, that's certainly an example of doing work in background to try to optimize what's going on. So any of these, the grading staff is going to be flexible as long as you stick to the design of the question on that. So if you're thinking like, well, wait a minute, how much flexibility do we give? Read the verbiage of the question on this. So as long as you're fulfilling that, you're good to go on this. Questions about this in terms of just essentially, I don't want to say it's a rote memorized, but this is about as close as it gets to it.  And again, that's the sort of thing really, probably five or six sentences tops because example, I'm sorry, hint example, hint example, done. Okay, question number four, Amdahl's Law. Now, reading here, remember a discussion of Amdahl's Law essentially that what we're talking about is if you work on improving one part of the system, typically the overall performance is going to be limited by the rest of the system. Remember back to 341 on this. My strong suspicion is that the people who, because you can see, most people did fairly well on this question, but the people who did not do well, it's probably because it's not because they didn't know Amdahl's Law, but because take a look at what the question is asking here. Just not asking you to state Amdahl's Law, but a particular corollary to that. So this is one of these, and it's not so much that we're being picky, but just do read and make sure that you answer what the question is asking for here. So in this case here, corollary was talking about that the longer you work on improving a particular subsystem, the essentially you're going to hit diminishing returns, the less result it's going to have in terms of improving systems performance on this. So that's what we'd be looking for. And then in terms of what we want to go beyond that is take a look at how this would guide you in the future. So you can say like, well, you know what? If let's say I'm really trying to tune the memory subsystem of my kernel, well, after a while, I need to kind of step back and see, is that still the biggest problem? And then maybe it is, in which case I need to keep working on it, but maybe not. Maybe I now need to, because I've exposed something else as being my biggest problem. So again, this question here probably could be answered or knocked off in two or three sentences, if that. So you don't need to list like all the equations for this, you don't need to go into lots of deep examples. Those will be nice, but the grading staff is going to simply say, do you know what the corollary is? And essentially, how does that apply your tuning and development of a system? Done. Question number five. And, okay, looking at the grades for this, it looks like this was a tougher question on this. But again, you know what? You might as well take a crack at it because, well, we're gonna pick the highest, actually the computer grading algorithm is going to scan over what the grades that were assigned and it'll automatically pick whatever the highest scores are. But question, okay, what's the difference between placing the buffer cache above the file system or below it? And if you recall, this was the subject of a couple specific lecture slides on this. So it's kind of specific, but you know, even if you, let's say you were completely hokey for that particular lesson. And you just, or you just don't remember that slide. I'm thinking, what were those, what were the pros and cons of that? You can probably reason this question out here. So in other words, where can we actually put the buffer cache here? So into the words above the file system or below the file system and what impact does that have here? Because, well, number one, what interface must the cache support at each level? And what's cached? And then, well, how does it kind of affect overall? So let's kind of take a look at these two things. Well, if we put the buffer cache above the file system, in effect, what are we intercepting? We're intercepting things in terms of OS 161. Well, remember the file system was given to you.  Well, your intercepting calls down to this from typically, let's say, the process file system, like a syscall or something like that. So your caching, in effect, let's say, opens, reads, writes, closes on this. So that's kind of what's going on in terms of the interface that we're dealing with. It's, well, a quasi-syscall interface that is what we're kind of having a cache in, well, the buffer cache on this. As opposed to if we put the file, the buffer cache below the file system, well, what does the VFS layer call down to? Well, I talked about this in one recitation, probably about two months or so ago. Remember, VFS layer calls down to the INO layer and eventually down to device drivers. Well, we're talking about accessing the hardware typically at the block level on this. So that's the, if you will, the interface that the buffer cache would be dealing with if we were putting it below the file system. We're talking about, let's say, dealing with it in terms of a block to be read or a block to be written on this. So there's pros and cons of that here. And what's going on in terms of, well, what do we want from this? We also need to know, okay, what's cached in each cases is it, let's say, data in terms of files or is it data in terms of blocks here? And how does that impact, well, how we do things on this? Well, again, there's pros and cons in terms of if we cache things at the file level, we can kind of get an idea about, well, what are the file access patterns? In other words, if this file X is read, we noticed from machine learning that file Y, it tends to be read pretty soon after. So we might be able to do some, let's say, prefetching or what have you. So we can study these file access patterns. That's something we wouldn't be able to understand with blocks because blocks, really, we don't know what they represent because remember, file X could be stored in one location in a disk, but then maybe somewhere else later on. So that definitely would be an advantage to having the buffer cache above the file system. But remember, Jeff also talked about if you put the buffer cache below the file system, what are we catching? We're essentially catching all IO on this. And that's important because in terms of the data that gets returned at the file system level, it's essentially just that, it's data. We're not really intercepting or dealing with metadata. And that's something, if we put the buffer cache below the file system, we're also gonna be able to cache things like inodes. And other directories are like bitmap or whatever it happens to be. We can cache that and speed that up too, which we would not be able to do if we had it above the file system. There's also another thing, kind of bonus points, if you noticed that putting the cache below the file system, you also don't have to worry about consistency on this too. Because if, let's say, at the file level on this, the user may think that, you know what, I've, let's say, done a call to fsync and I think that all the stuff is written out. Well, you know what, that may or may not be the case here. As opposed if we, let's say, put it below, we're actually gonna have, be able to eliminate some of these potential consistency issues. So again, this is something, my guess is, it requires a little bit more thought and that's probably why the scores on this particular thing were a little bit lower. It's also, it is a somewhat detailed question. It picks from a particular part of a lecture. But on the other hand, even if you didn't remember what those were, you can probably sit down and puzzle out and get a lot of points from this. Because, well, what is it? What, what is it that the file system expects and what is it that the file system kind of needs from the lower levels? And I can probably at least take a pretty good guess at what it is that the graders are gonna be looking for. Moving along, question six. And actually, whoops, you know what, in the interest of time, so that unfortunately, I don't have three hours here. I think I would bore you to tears if we did that today. Let's actually kind of skip ahead to maybe some of the, well, take a look at, let's say, the mid question, question number eight, virtualization. And here, essentially, what you're gonna be asked is, let's take a look at the three types of virtualization that are out there. And well, obviously, you need to know what they are. But what we also wanna know is, okay, what are the three types? How do they work? And what are the mechanics of making them work? What's virtualized? In other words, what's the interface that we're dealing with in terms of virtualization? And what are, essentially, the pros and cons? Again, in terms of this, it's stated like, what are the challenges to this virtualization approach? I can tell you, when you take your exam next week, most of the essay questions are going to involve, what are the pros of this approach, and the cons of this approach, as opposed to the pros and cons of this other approach? So if you haven't discussed the pros and cons of multiple approaches, you're probably missing something in your answer. It's just, again, it's the way these essay questions tend to be structured. So let's kind of take a look at these. First one, remember, full virtualization on this. And what are we, essentially, virtualizing? An entire operating system. And at the hardware level, we're kind of providing, well, we're not kind of, we are providing virtualized hardware. We're faking out a guest operating system on this. So that's what's being virtualized in the mechanics. What we'd be looking for as a grading staff is, obviously, you've got a guest operating system, you have to have a host operating system, and you also need, remember this widget, this VMM virtual machine manager, that's the virtualization tool. So in other words, you've got a host operating system, then an application, the VMM, and then above that, we've got the guest operating system. So those are the parts to it. Now on, and we would expect you to discuss a little bit about how it actually works here. And, well, we're saying, well, we're running the guest operating system as a program. Well, that's great, except what? What happens when we run programs that think that they're operating systems? You've got this problem with member traps because user programs are gonna be doing things like executing SysCalls or referring to locations and memory.  So this is the big challenge with full operating. I've got full virtualization, and this is what you need to do to solve it. Remember, this was the whole thing that was a big discussion about 15 years ago. Essentially, you have to kind of keep reading ahead and sometimes pre, let's say, compiling or recompiling on the fly certain instructions so that the guest operating system doesn't trap. That's what makes this all work. So logically, we get the same result, but what's going on is the operating system, we're gonna try to run as much code natively on the CPU, but some of it, we're just not gonna be able to do that. We're gonna have to intercept calls on the fly. And again, this is one of the things we talked about yesterday, kind of just in time compiling. Well, this is the very real use for that in terms of inserting stability into full virtualization. Now, it's gonna make it slow, but on the other hand, the nice thing is it works for all operating systems, and it's a great drag and drop resource for legacy systems. So that in a nutshell is full virtualization, and frankly, we would probably want you to mention all of that, the fact that it's full virtualization, the three components, the big challenge is we have to intercept traps, and we do that by recompiling on the fly. The benefit is we can essentially virtualize everything. And I know I as a grader, as a matter of fact, I did grade this, that is what I would be looking for in order to ladle out the full credit for the full virtualization on this, as opposed to let's look at the next one, per virtualization on this. Well, this also involves a guest operating system, and a VMM, although it's typically called a hypervisor, but kind of the same function here. There's no host operating system, though. So that's again, it's one of these, that's one of those, you just need to remember that. Don't mention it because points get lost that way. And the genius behind per virtualization, and the subject of research on this too, is remember the problem with full virtualization is it's slow. We're constantly having to read ahead and compile and interpret this. Well, remember this is the old software paradigm of dynamic versus static on this. Instead of having to do dynamic translation on the fly, let's do it statically. Let's kind of take a look at the guest operating system, where the problem children are in the guest operating system, and in effect, change things ahead of time. That's why it runs a lot faster. Now, the fly in the ointment with this is, we have to make these changes ahead of time, which means we need essentially cooperation with the guest operating system. In the case of something like Unix, that's great, where I should say Linux, it's open source. In the case of Windows, that means you're gonna need the support of Microsoft because they've got their source code in a lockbox. But again, it can be made to work, and it is made to work. So I would expect you to mention the parts in terms of guest operating system, a virtual machine manager. Again, there is no host operating system. We would expect you to talk a little bit about the pros and cons. It's gonna run a lot faster. As a result, it's great for running server farms on this. Con is it does require cooperation from the operating system designers on this. And kind of brownie points if you talked about the Zen people who got this actually working, they took advantage of the fact that, let's say, the Intel chips have multiple levels of privilege, so you can actually run the hypervisor at the really highest level of privilege, and then you've got the hypervisor and the guest operating systems at a middle level of privilege, and then the user programs at the lowest level of privilege. So that was kind of like a nice genius insight that they took advantage of. Then the last part, the container virtualization, again, the source for that was the research paper that talked about phones and how can you run multiple guest operating systems on a phone. And here, what are the parts? We've got a host operating system, but we don't have a hypervisor or a VMM per se. What we have is provisions within the host operating system to virtualize the namespace, hence containers on this. So we have, let's say, each pseudo operating system, all we're really doing is we're peeling off various levels that, let's say, I can have a copy of Microsoft Windows running in this instance, and, well, actually not, let's say, its process ID is X, but I'm running the same program in another guest container, and its process ID is Y on this. So I have to virtualize things like process IDs, file handles, namespaces on this. The upside to that is that what gets virtualized is at a much higher level on this. I'm not running an entire guest operating system. I'm only running one host operating system and a whole bunch of guest containers on top of that. So the downside is I have to have support for this from the operating system. I also am limited. I can only run one type of operating system. For example, like with full virtualization, I can virtualize Linux next to Windows next to perhaps even a gray market copy of OSX, all on the same machine. As opposed to container virtualization, if I'm running Linux, I can only have a whole bunch of Linux containers of the exact same type. Plus side to that is since it is lightweight, it's going to be great for resource constrained devices like a phone on this. So again, that's what we'd be kind of looking for for these three levels of virtualization on this and what are kind of some of the pros and cons. So questions, comments about this? And again, that was a discussion of the 20 point question for the others. Take a look at it. It's essentially, I would say the only big thing, I'll just mention this very briefly, like something like the heterogeneous cores thing. That's a case of Jeff is talking about if you've got two chips, okay? I'm sorry, two cores, a big core and a little core and how does it impact the various systems? You can see right away, you're going to have to discuss how it impacts virtual memory, how it impacts CPU architecture, how it impacts threading and processes. So it's cutting a wide swath across different topics and that's what he did expect you to discuss. And then the same thing is true in terms of the last question on this, in terms of let's say that we had a whole bunch of memory in the future, rather than a simple hard drive and dynamic memory, we're just going to give you a terabyte of flash memory and how does that change your system design on this? Again, it's going to impact files, it's going to impact processes, it's going to impact virtual memory and we would want to see a discussion of this. Make sense? Okay, we'll stick around as long as there's any questions, but good luck people. Thanks for taking OS 421-521. Yipper, our pleasure.


Hello everybody, welcome back to another Adobe Premiere Pro CC 2021 tutorial. In this one, I'm going to show you how to fade video in and fade video out. And the fade video out is often called fade to black. Okay Metallica fans, here we go. I'm going to show you how to do in about two minutes. So I'm just going to delete all this stuff here. And we're going to start from scratch. I've got some footage in the project panel, drag and drop it into the timeline. Now, simply take your playhead and move forward to about two seconds. Yeah, let's go to two seconds. And what you do here is you actually want to cut it. So I'm going to go ahead and I'm going to go and grab my razor tool. And I'm just going to snip at the two second mark. Okay, good. So we've snipped it. Now I'm going to go to the end and this is for the fade out. I'm going to go ahead and snip that too. So I'm going to go to 2408. And that means I got to go to 2208, which is two seconds exactly. I'm going to go Command K because I'm on a Mac. And that is the other way to snip it or cut it. So we've cut two sections off. So this is now three pieces of video. Take your playhead, push it to the beginning, left click on the first video, the first cut, pardon me.  Left click on the opacity stopwatch or the opacity toggle animation. Tune that down to 0%. That means we're starting from black and now go right to the end of the two seconds and pull it up to 100%. What does that do? Simple. Starts black and it fades in. That's all there is to it for a fade in.   But here we want to do it a little differently. We want again, click on the opacity. We're going to left click on it. So it starts at 100% and we want it to go to 0% or fade to black. Take it down to 0%. You'll see here that it's got a downward slope. So when we click on it, right fade to black. That's how you fade video in and fade video out. That's all there is to it in Premiere Pro. Thanks for watching. I'll be back soon.


So today, we are going to talk about the open source compliance challenges in our semiconductor company and how we overcome those difficulties. So we hope you will gain some ideas for complying with the open source license of your products. So let's get started. So here is the rundown for today's discussion. So we have mainly four parts. First, we will discuss common issues in the license clearance workflow. And in the next two parts, we will explore the challenges and implemented solutions in our semiconductor company. So lastly, we will showcase our contribution activities. So before moving further, let me introduce ourselves quickly. So I'm Shimomura. So I've been an embedded engineer for extensive periods contributing to the development of various products such as camera, TVs, and video devices. So over the years, I have also been actively involved in development using open source. And now I have initiated and managed the companies of Ospo. So OK, hello. My name is Yuji Honda. I work for Sony semiconductor solutions. And I have a various software engineering experience like software embedded into TV or camera or some kind of farmwares or SDK, your UX, machine learning, and so on. And last year, I created an Ospo in SSS. So today, I will talk about the experience. Thank you. So next, let me talk to you about our company. The Sony Group consists of several segments, including game, music, picture, and entertainment technology, and services, and imaging and solutions, and financial services. So we are Sony Semiconductor Solutions Corporation. So it's wholly owned subsidiary of Sony Group Corporation. And that's where we come in. And Sony Semiconductor Solutions has many subsidiaries as shown in this slide. Our primary focus is on image sensor development. But we also have a lot of software development. Naturally, we frequently utilize and control it to a diverse range of open source software. Sometime managing and figure out all OSS activities in our company can be challenging. So now we move on to the license clearance issue. As you are aware, achieving open source license compliance can be challenging. In addressing those challenges, we have established an internal open source compliance management process. And we are proud to be open change certified. So, oh, sorry, I'm essentially grateful to the open source change community for guiding us in improving our processes. So, however, it's important to note that our compliance process is stringent, detailed, time consuming, and not always easy to grasp. And also, it's difficult to execute because it requires software engineering expertise. So this slide shows that dependency analysis is difficult. We need to know all dependencies, not only direct dependencies, but also indirect dependencies. And to investigate all dependencies, we should check like package metadata. But metadata may, sometimes may be wrong. To solve this issue, we need detailed knowledge of building system, building system, and build configuration for each product. Sorry. So we have also another difficulty. So another difficulty is license investigation. After we identify software components, we investigate license of each component. There are great scanning tools like Phosology, and so on. In fact, we use both of them. But to identify appropriate licenses, we need to be familiar with those tools. Scan result containing may false detections. We need some know-how to deal with them effectively. And of course, open source license knowledge is needed. So, okay, so I pass to you. Okay. And previous slides show that common issues in open source license compliance. And next, I'll show you unique challenges for us. Okay, this slide roughly describes product domain of our business in SSS. And as you can see, it's very wide. And we have great sensor devices, of course. And we want to make the world better by great solutions utilizing our sensor devices. But it is not easy to bring out the potential of sensor devices. It requires expertise of sensor devices. So there's a big gap between sensor devices and solutions. To provide great solutions by leveraging our sensor expertise, we do all, from edge to cloud, to fill the gap. And we consume a lot of open source software to make our products. Open source software constitutes more than 90% of our product. This makes our open source compliance very difficult. Here's some example of our software product. The left one, one of our main products, image sensors. And firmware built into them. And we distribute device drivers to control the sensors. And we also have development board. And it's a kind of small computer. And it works with firmware, device drivers, and OS, middleware, SDKs, package managers, apps, and so on. And of course, we make camera devices. And as described in the previous slide, we have platform as a service business. And it involves server software, managed services, and so on. So our various software products make our open source compliance very complicated. For example, dependency analysis. How to identify open source components. When we make camera devices, we define build dependencies and customize build options. And compile source code to generate binaries. We need to read source code and build logs, like configure script or make file, see make list, dot text, or running LED commands, and so on to analyze dependencies. And on the other hand, when we make web service, we use package managers. And refer to package metadata. And use pre-built binaries. We should use dependency analysis tools, like app cache depends, or pip depth tree, or npm list, or sift, or something like that. So different product needs different techniques. Another example, open source license policies. It depends on how open source components will be used. When we make camera device, open source software will be embedded into product. It's distributed in the market, and software update will be done sometimes. But when we make web service, open source software will be run on server, accessed through web browsers, and software will be updated frequently. So when we define policies, we need to define different policies for the same open source license, considering how we use components. Some license cannot be used in camera devices, but it's OK to use in web services. So different products needs different policies. Here come some problems. When building software, build options are defined. Build options differ depending on products. Changing the build options may change licenses. What should we do? Then many binaries are generated from one repository. Each binary may have different licenses. Which license should we comply with? Or container image consists of a lot of many, many, many open source components. And sometimes, some products use container as built environment internally. And some web services use container on server to run programs. Should we do the same for both cases? Maybe some of you don't know how should we do, but some developers doesn't know. So as I explained, we deal with various software products. To comply with the open source license, both product-specific knowledge and open source expertise are needed. This was a big challenge. So how we navigated on open source compliance. This is our solution. We assign dedicated developers in charge of open source compliance for their products. Only product developers know the detail of their product. And we created Ospo consists of open source experts to support developers. There were few experts in our division. We need to train our Ospo members. But fortunately, there are some open source experts in Sony Group, so we learn a lot from them. This is our Ospo created last year. Ospo and product developers work together to comply with open source license. Our Ospo consists of various experts. One manager is him, and one leader is me, and eight collaborators, including legal members or IP members, and seven dedicated support members in India. We engage with about 30 projects. And we have some types of activities. We define internal rules. We provide engineering support and strategy planning. And license clearance support team have very important role in our Ospo. Our license clearance support team are in India. They are open source experts. Last year, they built an environment to proceed license clearance. And in every process, they work together with product developers. Today, some members here in this session from here in India. So please talk to them after this session. And here is a real example of license clearance. Sorry, it's very complicated. But this was the real log of our process. And this was for open CV 4.5. And in this case, 57 binaries are generated from one source package. And product developers and Ospo communicates on GitHub issues. First, product developer create a request and share some detailed information for building binaries. And then Ospo member confirm the inputs, then give some advice about patents. This one is not the license issues, but we advise them about the patents. Then, run some tools for scanning source file like Phosology. After checking scanned results, use shared information from developers to investigate the result in detail. In this case, very long log is here. And then identify license for each binary. In this example, it takes a long time to identify because there were 57 binaries. So it takes a lot of time. Then Ospo review the results. And after some modification, we prepare complex artifacts like S-forms, or license text, or copyrights, source files. Then we release them to product developers finally. And it takes about one to two weeks per package. The point is Ospo experts ask product developers for hints to identify license for each binaries. This approach is good for both Ospo and product developers. Ospo experts can acquire wide and practical knowledge of open source. Ospo can also optimize support workflow for products in this feedback. And product developer can concentrate on their development to make their product better. And they also can learn what they need to do for license compliance. So this could be another feedback. And finally, I'll show you some of our contribution activities. Partnership with open community is very important for us. This picture is very famous for Ospo members, I think. And thank you so much to use this in this slide. And for the first step, we strictly comply with open source license because we have respect for all developers in open community. So we do all for open source compliance in Ospo members and developers. And the second step, our SDKs are released as an open source project. And we want to improve them with open community. And finally, to support open community, aligning with our business strategy is also important. But we sponsor community events, like such as this year's Open Source Summit Japan. We sponsor this event. And Ospo encourages developers and business division for contribution in many ways. So these are today's key takeaways. First one, to comply with open source license for barrier software, dividing the work between Ospo experts and product developers is realistic way for us. Through this activity, Ospo experts can acquire wide and practical knowledge of open source and product developers can make their product better. And finally, Ospo experts also discuss open source strategies and encourage product developers for contribution. So that's all for today's session. Thank you very much. Okay, any questions, comments? Thank you very much for the great talk. And I think that the activity is very nice. So my question is that your Ospo structure is very good, I think. So how did you find out such a structure or such a way? Did you have some experience or some know-hows before start up the Ospo? Or did you refer to some reference? Or did you think by yourself? How did you find out the structure? Okay, thank you for the question. What we done first was to investigate what is the issue for us because we have many project involved and they have unique issues each other. So we gather all of the issues and analyze them and we define some requirements for Ospo for us. And then we, of course, we refer to some existing example like to the group provided and we decided which one is best for us. And the conclusion was this structure for us. So not only internal discussion, but also we refer to open discussions. Is that, that was the way we did. Thank you very much, I understand. Thank you. Thank you very much for your very, very impressive talk. May I see some slides after, again, yes, sorry, more, no, more, yes, yes, yes, yes. In this case, so one thing I'd like to ask you is the, how to say the right side and the down side, the prepare compliance artifact. That means the license clear supporting and the tooling teams will make the, how to say, the license notices for the product or services and just give the product team. So it means the development team doesn't need to make any kind of notices by their selves. Mike, understand it's correct? Yes, because we Ospo and product developers works together. So we communicate very deep in detail. So Ospo member prepare compliance artifacts for release products and they just receive the result from Ospo and they release to their customer. So in this case, may I ask this, but if I can, I'm very happy to ask you. So in this case, in your company, the whole kind of nice artifact, sorry, kind of the document of the notices is managed by Ospo. I mean, whole kind of product, sorry, the notice of all kind of product and the services will be managed in Ospo. Responsibility to release the artifact is belong to development team. So finally we give them to manage the compliance artifacts. But the Ospo member have the responsibility to prepare the compliance artifacts. Thank you so much. And this is my last question. May I? Would you please show me again your structure of the Ospo? I guess it's in this illustration. So I couldn't find the security teams. So do you have any collaboration with the security or security assurance team? Yes, of course. We have another security team out of this figure, but we communicate very much every day. And how should we handle with the vulnerability of OSS components? So I think we should add another box here. Thank you very much. But the security guys doesn't include the Ospo. Just the security as it is? Both. Because we are in the same section, security team and Ospo team are in the same section. So we do the same for open source security. Again, thank you very much. Hello, thanks for your sharing. I come from Taiwan and I come from the organization, OCF, that really wants to establish open-chain culture in Taiwan, but now we've tried to let company know how important the open-chain is and help them to build the Ospo. But we really don't know how to make them understand the importance. Usually they will ask us about we might have some risk of the litigation, the suit of the open source license. But if you want to provide them some assistance, they will just ask the license mentor, consultants. But they don't really want to establish the ISO 5230 and build the Ospo. So I want to ask, how did you build the Ospo from the beginning and what were the challenges you face inside your company? Thank you. Okay, thank you very much. Fortunately, Sony has a long history about open source relationship, like CELinux contribution or something like that. And we have both idea about the good side of the open source contribution and risk of open source consuming. And what was good for us was that most of the managers know about the risks of open source consuming. So we started with open source compliance first. So that was the first step for our Ospo. And then we talked with managers about the open source activities for the next step and not only for risk reducing activities, but also how can we utilize open source as a strategy, strategically. And they agree with us so we could build this kind of full functional Ospo. So, yes, I think this was very specific for Sony's case, but you can refer to our example. Thank you. So in terms of like, well, there's open source compliance, but in terms of the supply chain, did you receive any pressure or influence from like your customers to provide them with compliance artifacts? Yes, it begins to feel like that. And our another team started discussion for how should we comply with the laws about this one more supply chain solution. So we also work with another team about thinking those kind of things. So the answer should be yes. So I'd like to ask again, that's a very trivial sense, but in my experience for almost all of Japanese company mainly they are using Japanese language for the documentation and some kind of trading materials or so, and so on. So, but in this case, in your case, so you're working with a team in India. So I assume the English is the main language for your operation, why not? Yes, you're left side persons. Yes, the developers and support team communicate in English, that's right. But how about the Japanese developers in your Japan country side? They try to speak English. Really? Of course, and of course I support them in English and Japanese to communicate fluently with India team. So it works for us. Thank you so much, thank you. Thank you for your presentation. And my question is similar to him. So I'd like to know the background behind the improvement of the members or branches. Because I imagine at first, if I start to make an Ospo, maybe initially to gather members, just Japanese. So my question is, what's the background to gathering the overseas members? It's difficult to answer, but I think it was another lucky things for us that we have a big group company. So we have a lot of subsidiaries in the world. And we already worked together in another projects like product development with the India team. So we could easily to start communication about building Ospo for us in India. So I think this one is also specific for Sony, but. Yeah, I think it's generally speaking, I think it's very difficult to delegate functionalities to other countries. Yes, I think so. Thank you for the presentation. Can you go back to the slide with the Ospo maturity level? I see that on stage four, you have the open source summit sponsorship. Do you also encourage internal developers to contribute back to community or you just give money to the different events? Yes, we really encourage developers to contribute back to each OSS community. And we are thinking about some kind of contribution back to OSS community. And we especially have interests in AI domain. So internally we have some kind of discussion about contribution for the OSS community with developers. Thank you. Excellent, five minutes we have. Five minutes we have. I also have a question about the contribution. How do you decide which project to contribute? Is it bottom up or top down? That's really difficult question, but currently we mainly bottom up approach because the open source technologies are very immersive and the top manager doesn't know that those kind of new technologies generally. So we bring up some kind of new news of the open source activities and they are doing this kind of things and we should do this also. We bottom up the proposal to managers and they also have the idea that open source contribution is very important for business strategy. So we can talk for both kind of view business and open source development. So in some project we are starting the discussion for contribution regarding the business strategies. Thank you. Thank you for the presentation. So I have a question about the, how do you organize the relationship between the developers and the OSPO members? How can you gather the engineers in this activity? Okay, this one involving developers to... Maybe previous slide, or this one, not this one. Sorry, oh, sorry, but my question is how do you gather the engineers, get the interest from the engineers to do this kind of activity? As we showed earlier, we have a certification for open chain and we already had a very strict process internally. So every product developer had a problem in proceeding the process. So they needed some help. And that time we created OSPO and we asked them for any help they need. Then they agreed to work with us. And also we provide, as you see in the left side of this, we provide them some kind of open source training for them. So we are working together good. Thank you. So which group is actually running your open source scanning tools like Fossology and FOSSID? Is that the group in India or is that the product developers? India team. So that means the India team has access to the source code for the different products? Yes. Regarding the source code, gathering all the source code to scan is a kind of big problem. So in that case, also this India team and product developers work together to gather all the source code to scan. Three minutes left. Can we close this session? Okay, thank you very much.


Medications. Danger. Young children may confuse medications for candy, which could lead to injuries or death. In 2021, 59 children under five years old died from pediatric poisonings after gaining access to drugs. Five medications accounted for over 25% of the 62,600 unintentional pediatric poisonings treated in emergency rooms. Protect children from poisonings by taking control of potentially harmful products and medications. Tips. Keep medications safely stored in a locked cabinet or box and out of reach of children. Keep medications in their original child-resistant containers. Unfinished or unused medications should be discarded properly. Ask your local pharmacy or police department if they have a disposal kiosk for medications. Never call Medicine Candy. Call Poison Health, 800-222-123-5222. Immediately, if a child swallows or is exposed to drugs or medication. Remember, poison awareness and control is for everyone.


The category of internal communications was a very very interesting discussion had by the jury purely because of the vital role that it plays in today's context. We saw a wide variety of entries across size, scale, objectives and overall results and congratulations to the winners.


Ladies and gentlemen, so I've said this is Anna and Emily. Anna has a written statement she'd like to make. You okay to start? On the right. Our brother, Julie, was brutally murdered last Thursday, the best day last week, and his body dumped in the Logan River. If you saw or heard anything on that night, I urge you to please come forward. Our brother, Julian, was a loving, loyal, caring, and considerate family man. He was a loving partner, a dad, two beautiful children, two and four, a stepdad, a son, a brother, a loyal friend, and was much loved by his very large extended family. My brother, Julian, and my family, deserve this. Please help my family find who's responsible. Thank you. Can you tell us a bit about Julian? He's an older brother. Do you always appreciate an older brother and a younger sister? Yes. What was he like with these children? He was such a caring dad. They were his life. A few days before? A birthday. And how was he? Very happy. Do you remember anything you talked about that day? A birthday celebration. Talked about family. These kids tied him down. Everyone was dead this day. His dad was his whole life. He had a son, he had a daughter. Did you like the older one? Yes. Did Julian like it? I'm not even talking about that. These children used to go to the playground. He was always playing football and soccer. With this little boy. He'd spend hours in the backyard, go to the park, took him to the skate parks, taught him to ride a bike, and a scooter. His family. The prongers. Questions? The investigation is continuing. We still have a number of detectives assigned to the investigation locally from the Logan District CIV in the Homicide Squad. We still have a number of appeals to make to the public. We're still interested in speaking to anyone who has any knowledge of the matter. Anybody who can shed some light on why Julian was in the Logan area on the night in question. Anybody who saw his vehicle, it's quite a distinctive vehicle as you can see. Anybody who saw the vehicle in the area or has any knowledge of its movements. Particularly we're interested in speaking with anybody who visited the Henderson Road or the boat ramp around about 8.40pm on that night. And also anybody who actually travelled Henderson Road from about 7pm on that Thursday night till 9pm on the Friday morning. As you can imagine we do door knocks in the area. The investigation has revealed that a vehicle attended the boat ramp around about 8.40pm. Significantly it only stayed for a very short period and we do not consider that person to be a suspect. We're interested in talking to the people who were in that vehicle that attended at 8.40pm so that we can basically establish whether they saw anything and just to eliminate them at least. We're still making inquiries along those lines obviously it's a very rural area and that's an ongoing inquiry. He resides on the north side and to our knowledge he may have come over at a time but we have no reason to believe that he would regularly visit Logan. So we're particularly interested in anybody who can shed any light on why he was in the Logan area that night. We are of the view that the murder actually occurred there on the boat ramp.