launch and hopefully not so fall to the extent that you would be able to follow what I'm saying today. So cost is a cornerstone of pretty much most of the decisions we take in our daily life. So we are trying to optimize or maximize the value of pretty much what we are trying to get even in our personal lives. It's pretty much the same for the cloud and that's what I'm going to talk about today. I'm going to talk about how we can maximize your business value through cost optimization with the AWS well-architected way. My name is Mohammed Wadi and I work as a solutions architect at AWS Solutions architecture team and based out of Amsterdam, the Netherlands, mini-acting or serving the enterprise and retail customers within Benelux region which is Belgium, Netherlands and Luxembourg. So before getting started I'm curious if any of you is already familiar with the AWS well-architected framework. Alright that's great to say. Was that has any of you really used the well-architected framework to run architecture assessments for your workloads? Well that's still good to say. So for those of you who are not familiar or have not run any architecture assessments I'm going to quickly cover that today as well. So before I get started I have a confession to make. This session is not really about you know the tips and tricks you can do in your environment so you can eventually save some costs for services. Instead it's more about the culture and the processes you need to embrace and incorporate into your organization so you can be eventually a cost efficient organization. This is our agenda for today. I'm going to first of introduce a well-architected framework what it is and what it really means to be well architected. Then I'm going to talk or dig deep into one of the pillars of the cost optimization framework which is into the cost optimization pillar which is one of the pillars of the cost optimization framework. Afterwards I will dive deep into the design principles of the cost optimization framework and here we can use it and use it to practice in order to eventually be a cost efficient one. And last but not least we're going to have some time for Q&A so please hold your question till the end and in case you know you didn't manage to ask your question or for whatever reason we ran out of time please feel free to reach me out right after the decision I would be in the building till the end of the day. So with that what does it really mean to be well architected? So over the years we have been involved in tens of thousands of architecture reviews with our customers and even internally and throughout the time we managed to see some successful patterns what really works well and what doesn't work out. Based on that we managed to extract a set of best practices that covers different aspects which works pretty much for most of the workloads we have worked with. These best practices are formed into pillars that eventually forms a well architected framework. The well architected framework is not meant to be an audit process yet it meant to be a review process so it should be helping you to regularly evaluate your workloads against the best practices. So it's not also a one-time thing so you might start evaluating your workload making sure it's even aligned with what we have but then maybe after six months you need to revisit it because we keep launching new services and key features which can if you incorporate it into your design it might help you to be more optimized over the time. So the well architected framework is built around six pillars security, operational excellence, performance efficiency, sustainability, reliability and the pillar we're going to talk about today which is cost optimization. The cost optimization pillar have five design principles. If you follow these design principles and manage to implement the best practices of these five design principles you can be eventually cost optimized. The first one is about to implementing cloud financial management. So to achieve financial success and accelerate business value realization in the cloud you need to invest in cloud financial management. It's pretty much the same like you know any team you have in place such as security or operations over the time you have dedicated time, energy and resources to make these teams mature nowadays we can see how mature our security teams and operations team are nowadays. That's mainly because over the time we have been heavily invested in that. You need to do pretty much the same for cloud financial management. This new area or this new domain of technology and usage management needs your time and effort through knowledge building programs and resources so you can eventually become a cost efficient organization. The second principle is to adopt a consumption model and what it means simply is to pay only for the computing resources you need and increase or decrease your usage based on your business requirements or business demands. A clear and great example is the different test environments we pretty much all have. You really don't need to run all of these environments all the time right? We work eight hours a day 40 hours per week so while running them for 168 hours per week which is the whole time so make sure that you're shutting down the resources you don't need if you don't need at that time and that would end up with savings of up to 75 percent. Number three is to measure the overall efficiency and you need to usually measure the business outputs and the associated delivery costs. So think about it as getting this kind of output or the workload I'm doing on a business level. However I invested this much time effort energy and money to get it. Is it really worthy? This kind of data is quite instrumental to help you to understand the gains you can make maybe from increasing the output increasing the functionality while in the meantime reducing cost. Number four stops spending money on undifferentiated heavy lifting. The cloud nowadays does take care of the heavy lifting of data center operations such as racking stacking and powering servers and it also removes the operational pardon of you know managing operating systems and even some applications by using the AWS managed services. This would allow you to focus more on business projects and on your customers rather than focusing on the IT infrastructure. And last but not least, analyze and attribute expenditure. The cloud made it way way easier nowadays to be able to attribute the right cost and usage to the right workloads which then allows transparent attribution to the right revenue streams and workload owners. This would help to measure the return on investment which is very important and can help the workload owners to be able to optimize their sources and reduce costs on the long term. So that how can we actually run this kind of well architected assessment? How can I do it? It's pretty straightforward and very easy. For that we have the AWS well architected tool. It's very easy to use, very straightforward. All you need to do is to navigate to AWS console maybe on the search bar search for AWS well architected tool and then you would be navigated to the AWS well architected tool console. From there you would be able to start a review, a well architected review for your own workload.  These questions have set of best practices that you need to comply to in order to say that I'm well architected. However, not necessarily all of these questions or all of these best practices could be relevant to what you're looking for eventually. And if that's the case you still can exclude some best practices, some questions, if it's not really relevant for you. So when you're done with a set of questions you wouldn't really be assessed again instead. If you're looking for further information about the best practices or the questions you have in place there is normally a hyperlink next to every single question and best practice. Make sure to click on it to gain further information about it. So once you run the AWS well architected assessment using the tool that's exactly what you get. What I have done here I have gone ahead and run an assessment and this is a result on getting just for cost optimization. I got 10 high risks because I really apply nothing of the best practices at this stage for cost optimization. So what do I need to do? First you need to add these 10 high risks. You might also be getting medium risks which is a best practice to address them. But for the sake of the time of decision we wouldn't really be talking about medium risk at all. So what we're going to discuss from now onwards is we're going to discuss the high risks. In particular we're going to discuss 5 high risks for the sake of the time session. As you see on the left side here these are 10 red circles. For every high risk we're going to address this red circle will turn from red to green. As you see here these are the best practices and on the top of it is a question. The ones that are grayed out down here these ones are the medium risks which we're not going to address today. So let's start off by talking about the cloud financial management part where first off you need to establish cost optimization function. And what it simply means is you need to have a cost optimization team. You can do that by first off identifying some key stakeholders from finance as well as technology. These two departments in particular need to work together in order to be eventually a cost optimization organization. To address this best practice all you need to do is to identify the key stakeholders, maybe align with them that you're starting out this new team and then you can create an email distribution list that includes them so you would be able to communicate with them further. And with that you can just check the very first best practice here. Next you need to establish cloud budgets and forecasts. And I know the cloud is kind of different because on premises we used to put huge investments up front into gears and stuff in order to eventually meet the big level which we might get at some point and we might not. That's a huge investment and that's the perfect thing about the cloud. You really don't have to do that. However it's tricky because you don't know how much money I'm going to pay eventually. That's why you should use a mechanism for forecasting your for forecasting how much you're going to pay for your resources that should be provisioned on AWS. For that there are a couple of ways that you can follow. One is to follow the trends way where you can use at all that I'm going to talk about just shortly called AWS Cost Explorer. This can use machine learning behind the scenes and give you some estimations about how much is going to cost you for the upcoming six months result. These kind of information are being extracted from your trends while working on AWS. The norms of spin that you are following. However this might not be sufficient because on the other side you still have a pipeline for projects that you need to work on. Sometimes these projects could be small while sometimes could be big which means also big investment that you need to put in place. So you need to ask yourself a question which way would work out for me. Normally for any customer at the beginning of their cost optimization journey I highly advise to merge both of the approaches in order to be able to have a more accurate estimation. Otherwise if you just follow the trend maybe you would be surprised with a big bill at some point. That's why I really would like to introduce my second favorite cost optimization tool AWS Cost Explorer. AWS Cost Explorer is a free of charge service that you can use whenever you provision your AWS account. Back in time when you provision an account you needed to navigate to the AWS Cost Explorer console and then enable it yourself. You really don't need to do that anymore. Nowadays it gets enabled automatically. However it still takes 24 hours in order to start to populate cost us for you. And over the time when it starts to populate costs you can slice and dice these costs based on the services, based on the regions, based on accounts. You can filter depending on how you'd like to filter it and gain more insights into what you have in place. And that can give you some decent insights about how we can handle the forecast. But in the meantime what can I share with the cost optimization team? Can I just ask them to log in to the AWS console and open the AWS Cost Explorer? Well that could be a way but it's going to be tricky especially we have people from finance and we need a more efficient way to communicate with them. That's why you should be also using the AWS Cost and User Report. The AWS Cost and User Report would give you granular insights into the cost us for your resources. So you can use it and even import it for visualization by other tools such as QuickSight or Redshift. What I have done over here as you see, I have just used QuickSight in order to analyze the data within the CSV file where I'm getting for example the monthly cost. I'm filtering based on how much services are consuming to what extent. I'm filtering based on the instance types so you can utilize such tools also to gain a decent visualization for what you have in place and that could be a great report to present for finance stakeholders. So in order to enable the AWS Cost and User Report, what you need to do, navigate to AWS Cost Explorer console, click on Create Report and from there you need to specify the S3 bucket to which you're going to import this report. It's taken well a few hours in order to start publishing it to this S3 bucket and then you can download it, maybe visualize it, maybe use it right away in your meeting within the cost optimization team. And now you have a cost optimization team and also a Cost and User Report. Now you need to establish a partnership between finance and technology by setting up a cadence for this team. A cadence where they're going to regularly meet, could be by weekly or monthly, depending on the size of your organization and how important these matters at this stage for you. Then you can introduce the Cost and User Report that you just got. These are a visualized one or the CSV file that you can export. And from there you can start discussing, are we really going on the right track? Are we meeting our business outputs, looking at the costs we have here? Is it really makes sense or are we really going the wrong direction where we are putting too much money and getting no value, even on the long term? That's the kind of discussions we'd be going through with the team over the time. Next you need to implement cost awareness organization-wide. So you can, of course, go ahead and create your own resources on the cloud, but there should be a process where the cost is being shared across different levels. So at least have a mechanism whenever you are starting a new resource provisioning, especially if it exceeds a certain threshold, maybe if it exceeds $50 per month or so. Maybe in the ticket you're going to create for provisioning these resources just as to shift the cost estimation. So the right stakeholder, when he or she looks at it, can be able to identify if it's really a good investment to proceed with, or if it's really too much to proceed with, or does it need an exception and so on. That's the kind of awareness you need to spread across the organization. And with that, we just managed to switch the very first high risk from red to green. Next, user governance. You know, you cannot really be cost-automized if anybody can just go ahead and create stuff, right? So you need to develop policies in place. These policies can segregate what kind of permissions these kind of teams have, what kind of permissions other teams have. So a good example could be the development team and operations team. The operations team might have access to many accounts with wider permissions, so they can maintain the environment. While development teams might need to just access the resources in which their application is up and running and so on. So just identify your business requirements. Identify rules. Create groups which you can use to segregate them. An easy way to do it is by using the AWS Access Management, which can help you to create your users, groups, and then associate the right policy that restricts their access. So instead of just going ahead and create whatever they would like to create, you would be restricting their permissions and what they can do. And from there, you can also, you know, segregate or restrict certain regions from creating these resources on it because over the time, if you're not using this region and allowing these users to create resources in this region, it might end up being charged for costs that you're not even aware of. Then you need to implement goals and targets. Remember the meetings you have was a cost optimization team? There should be some goals and targets that you would be discussing for every workload in these meetings. Some of these goals could be that by next quarter, I would like to increase my business utilization or my business consumption for this workload, while slightly increasing the cost of the workload. That's the goal I have. But the target would be that for the increased consumption, it would be by 20 percent. And for the cost increase, it would be 5 percent. So make sure you have accurate data points that you can count on and that you can assist yourself against it. Then you need to implement an account structure. It's really quite hard to apply governance and would be quite complex if you have tons of resources in a single account. So you need to have an account structure in place where you can segregate what the different teams are doing and where the different workloads are living. That could be that the team is doing workload one and it totally doesn't have to do anything with workload two. Or even if it does, you still can, by using other tools, enable them to communicate together somehow. But at least you would be making it easier for yourself to segregate the kind of policies and the kind of rules you're going to assign to the different people that is going to access these resources. And with that, you can use AWS organizations. So AWS organizations is an AWS service that can help you with account provisioning and also governing the whole accounts. So you can create an account with a certain permissions in place or certain policies in place that restricts what can be done and what cannot be. And few benefits of it is the shared identity and access management. So instead of having to create your identity and access management for every single account by assigning a certain set of permission for a certain user in every account, that's a tedious and long process. With AWS organizations, you really don't need to do that. What you can do instead is just to centralize it in a single account and this account would be your kind of hub to assume rules to the other accounts. You can also consolidate the billing. So having a dedicated billing for every single account is a tedious one as well, especially when you try to extract the cost and usage reports and how long the process would take while you have to go through for a very, very big number of documents you have in place to review your costs in it. Number three, the shared users credit. So if you have any users credit that AWS has granted you, if you're having a single account, not part of an organization, then it's going to be dedicated just to this account. However, if you're using AWS organizations, it can help you to spread it organization-wise for the different accounts you have. Unless, but not least, to share the reserved instances and that's where you really can have a reserved instance, which is a set of commitment that you make to use certain types of EC2 instance for one or three years. If you're making it for a single account, it's dedicated to this account, but if you're using AWS organizations, you can share it organization-wide. And it makes sense here mainly because if you decided to shut down an account where you still have some EC2 reserved instances, in this case you still can put it somewhere else and invest it somewhere else. So with that, we managed to switch or flip the second high-risk into green as well. Third is usage and cost monitoring. So for the time being, we have AWS Cost Explorer where we are monitoring our costs, but it's just getting updated every 24 hours. It would be nice if we can really gain more detail than sites. So instead of 24 hours, maybe it would be nice to gain insights every one hour, especially if you're deploying a new workload and you don't want to be surprised that the cost has insanely increased after 20 hours or so. And you can easily do that while the AWS Cost Explorer console where you can navigate to preferences and from there you can enable it, which is pretty straightforward as you say. And it's going to take 24 hours to start updating the cost every single hour. Next, you need to identify cost attribution categories. And you can do that by having a meeting with the key stakeholders in finance that can help you to identify these kind of categories. It could be the kind of tags that you would eventually assign to your resources, such as a cost center maybe, the environment name, the workload owners and so on. Then you need to establish workload metrics. And that's very critical here, mainly because if you really can't track the value, the business value of this workload, it might prove that it's not efficient after a long time, which means also huge losses. So here you need to identify what really matters business-wide as well, such as maybe the number of page views, the active subscriptions, the seconds of the interaction with your application. It really depends on your case. I'm just mentioning some examples here. So for that you can use Amazon CloudWatch, where you can publish these kind of metrics on it, and set up some alarms to be notified whenever it exceeds a certain threshold. So for example, if the number of active page views drop to less than 50 percent, then clearly there's something wrong. Maybe you're under attack. Maybe your application is facing technical difficulties and so on. And that would be the moment you really need to start engaging. Then you need to configure billing and cost management tools. If there is something that I really want you to take out the decision today, it's exactly this one. Make sure you are creating budgets. Normally when I start having conversations with a customer, I make sure that up from the customer, beside using a work and a company email for the root account and enable an MFA, it's actually to create a budget. For that you can use AWS budgets, which can help you to set some limits, based on which if you exceed, you would be notified. So you really know what to do next. By default, it doesn't take any action, but you can integrate it with other AWS services, which can really help you maybe to shut down resources, for example, if you'd like. And you can identify budgets based on actual amount of money or based on forecasts. If you're using forecasts here, it's going to use the forecasts of the AWS customer explorer and notify you that by the end of the month, you're going to exceed this amount anyway, so maybe you need to take an action. And for that you can be notified by SMS, by email, or by chatbot notification, which can stream these notifications to your Slack channels or time rooms. Creating it is very straightforward as well. Just search for budgets or go to AWS customer explorer console and under the budget section, that's where you can create it. I didn't find the things are very straightforward as you see here and once you're done with the parameters you need to provide, you can just create and you would be notified from now onwards if these thresholds are exceeded. And now we have managed as well to flip the shared high risk from rate to grade. Next you need to decommission resources. And that's, you know, one of the most important things, because I have never seen a resource that's meant to live forever. At some point you need to decommission this resource. So for that you need to really track the resources over the lifetime. If you're just creating the resource and not really aware of where this resource is or what is, when should I decommission it? That's a bit of a tricky one. That's why you should be using tagging. Tagging simply labels that you assign to your AWS resources. It's a key value bearer that you can use to gain more insights or make the data about this kind of resource. For example, which environment this resource exists in. Maybe what is a cost center I should charge back for that resource. So on and so forth. And then you can even visualize these kind of resources or how much, for example, all of the resources associated with a certain cost center, how much money it's costing. So on and so forth. So you can use that as well to gain more insights on cost on the tagging level as well. After identifying a way to track your life cycle of resources, you need to implement a decommissioning process. And for that, you really need to make sure that you have a way to decommission the resources eventually. In order to make it easy for you, I highly encourage you to use infrastructure as code if you're not already. Using it this way can help you whenever you decide not to proceed with these kind of resources, can just go ahead and decommission it. However, if you have a hand-created resource, you still need to decommission it. But to make it easier for you, and maybe because it's a new resource that doesn't support infrastructure as code at this moment, at least try to track it via tagging. This would be helpful later on, so you'd be able to find this resource and decommission it. And now we managed to flip the force high-risk from to green. The five question is about evaluating services. So you need to identify organization requirements for cost. How can you do it? So think about it as an example where you need to provision a workload that needs a database. This database could be provisioned in EC2 instances, but could be provisioned on RDS as well, which option you should go for. EC2 instance sounds more appealing because it's cheap, while Amazon RDS sounds more expensive, but that's not really true. It's not really true because there are also some hidden causes here. If you are under the pressure of time, or if you don't have an experienced DBA who can really manage the database, clusters, and maintain it over time, that's too much cost and stress for you, which, although it's not a sensible cost, but it's gonna look you at some point. So use your judgment over here. Do you really have the skills and have the time to proceed with an option that sounds more cheap, or should I go for that option that sounds more expensive, but it's gonna help me on the long term? Then you need to analyze all of your components of the workloads, and then run a thorough analysis for them. You can do that by making sure that you're going through your every component you have identified in your architecture, and then evaluating if it makes sense. Should I replace it? Should I decommission it? Because sometimes at initial stages we just add some components to solve a certain workaround, but over the time it might no longer be needed or could be done in a better way. Well, my advice here is if you are planning to, you know, if this resource or component is costing you not too much money, let's say five dollars per month, and you are under the stress of time, and it's not having any severe impact like a security impact or so, maybe in this case it's not worthy of your time, but if it's costing too much money, if it's costing too much pain, then you should really go through it. Last but not least here, to select software with cost-effective licensing. I normally advise customers to use open-source software, but even the open-source software which can result in significant workload optimization from a cost-effective perspective, sometimes some of them are licensed as well. Well, if that's the case and if you really need the tool, at least make sure it's not bounded to an arbitrary attribute, such as CPU. I do remember a customer who asked me if they can really provision an EC2 instance with a 512 gigs of RAM and just two CPUs because you were bounded to the CPUs. So make sure that you don't fill in this trap and instead, if you're going for a license, make sure it's more oriented to the business outcomes and results you are trying to achieve eventually. With that, we managed to flip our fifth high-risk, and we are gaining a momentum over here, but we are only half the way. We still have five risk issues remaining, but we don't have the time. As I mentioned at the beginning, I'm just going to add this five high-risk. That's why I highly encourage you to visit the cost optimization pillar documentation. That's where you can gain more insights about every single best practice and every single question that we have discussed so far. So with that said, I really would like to wrap it up. So these are few key takeaways that you should really be considering out of decisions starting from creating a cross-functional team that has people from finance and technology. This team would be the foundation to eventually become a cost-efficient organization.  You really wouldn't like to be surprised by a budget four times or a bill four times more than what you have initially estimated. By creating budgets in place, you'd be notified up front when this happens right away, so you can address the problem as soon as possible. Create a life cycle through your resources. This is a very important one as well, so you can really know what these resources are meant for and what you can do with them whenever you would like to decommission them, otherwise it's going to be, you know, a long journey trying to search for the orphaned objects and resources here and there. And last but not least, regularly check cost-against-exemptations. Make sure that the associated costs or the associated delivery costs of the workload you're architecting is really bringing value to the organization. Otherwise, you might need to revisit it. That's it. I really thank you for your listening. In case you do have any question, I would be more than happy to answer.


Let's solve a couple of questions on image formed by multiple lenses. For the first one we have two convex lenses L1 and L2 having focal lens F1 which is plus 7.5 and F2 plus 10 and they are placed along a common axis. These lenses they are separated by a distance D over here that is 40 cm. And it also says that an object O is kept 30 cm in front of L1. The question is to figure out how far from L2 will the final image be formed. And there is a note which says to use the proper sign convention while reporting the answer. Alright as always why not you pause the video first and give this a try. Alright hopefully you have given this a shot. Now we see convex lenses L1 and L2. So first let us look at the lens equation there it is. This will be used throughout the question. Now the question is asking us to figure out how far from L2 from this lens will the image be formed. So it is interested in figuring out the image distance from L2. And for L2 we know the focal length. The question is asking us to figure out the image distance. So we could do that if we knew the object distance. So then using the lens formula we can plug in the values and find this V. But we don't know the object distance for L2. We know that for L1. We also know the focal length for L1. So using the lens formula we can figure out the image distance for L1. We can figure out how far from L1 will the image be formed. Then that image the image formed by L1 that image can act as an object. It can act as an object for the second lens. And turns out for multiple lenses that is a common strategy that we use. The image formed by the first lens that acts as an object for the second lens. Let's write that down. Image formed by first lens acts as an object for the second lens. So we will need to use this relation toys. First for figuring out the image that is formed by the first lens. The distance of the image that is formed by the first lens. And then use it again to find the image distance for the second lens. So let's use it once. We know there is an object in front of L1. So this distance would be U1. And there will be rays coming out from this object which will pass through the convex lens. They will undergo refraction and because it's a converging lens they will converge to a point. And that is where the image is formed and this distance is V1. Now we know what U1 is that is the object distance. We know what the focal length is. We do not know what the image distance is. So let's use this relation to figure out the image distance. So this becomes 1 upon V1 minus 1 upon U1 that is equal to 1 upon F1. If you put in the values this becomes 1 upon V1 that is equal to 1 upon 1 upon 30. Because U1 is 30 plus 1 upon 7.5. Now we need to think about the sign convention as well. We need to think about the sign convention. Using the sign convention in the numericals it involves treating the optical center of the lens as the origin. So for this one we can take that this is the origin. Everything on the left hand side of this origin could be negative and on the right hand side could be positive. So U1 here would be minus 30. This would be minus 30. Now we can work out this. So 1 by V1 this is equal to we can take an LCM of these two. We can get 30 itself and in the numerator we can get minus 1 that's just this one plus 7.5 into 430 so plus 4 and this is 3 by 30 and this is 1 by 10. So when you invert it finally you get V1 as plus 10 centimeters. The sign convention fits what would really happen. It's plus 10 and everything to the right hand side of this lens should be plus and it's forming at a distance of 10 centimeters from L1. So this V1 is 10. Now the image created by L1, the image created by L1 it acts as an object for L2. So this distance right here that is U2. This is U2 this is the object distance for the second lens. And after going through refraction it meets at the optical axis and an image is formed at a distance of V2. So now we can use the lens formula again, the thin lens formula again to figure out this distance V2 and that is what the question is interested in. So when we do that this is 1 upon V2 minus 1 upon U2 that is equal to 1 upon F2. Now here we know what F2 is that is plus 10. U2 would be this total distance D minus V1. So U2 is D minus V1 and that is we know what D is that is 40. 40 minus 10 this is 30 centimeters and when we are placing it in a thin lens formula we do need to follow the sign convention for the lens L2 this point can be treated as origin everything on the left hand side would be negative on the right would be positive. So 1 upon V2 this becomes equal to 1 upon minus 30 plus 1 upon 10. The LCM could be 30 and this is minus 1 plus 3. So this is 2 divided by 30 that would be 1 by 15 and V2 comes out to be equal to 15 centimeters. So the answer is plus 15. All right let's move on to the next question. The second question says that a person who cannot see far away objects clearly is said to be myopic. We can correct this condition by using a concave lens in front of a convex lens. So again we have multiple lenses now we have concave in front of convex lens of the eye. This combination can focus the image on the retina.  The distance between the two lenses concave and convex is 0.5 and the question is to figure out the distance of the retina from the eye lens. One important note it says assume that the object is far away so the incoming rays are parallel and we need to report our answers correct to two decimal places. Again pause the video maybe try to draw the entire setup over here and attempt this one on your own first. All right hopefully you have given this a shot. Now for multiple lenses I always find it helpful to draw what the question is describing or or stating. So here we here we have a convex lens a concave lens and also there is a retina where the image is formed. So I would start with drawing where the retina is we don't need to really draw what exactly retina looks like but maybe the retina is at this place over here and there is a convex lens in front of it so there could be a convex lens here and there is a concave in front of the convex so concave lens could be over here and the question is asking us to figure out the distance of the retina from the eye lens so let's let's label that distance that distance would be a distance would be this right here this distance D right here that is what the question is asking us to figure out we know what the focal lengths are and the question also tells us the distance between the concave and the eye lens so let's let's write that also this distance is 0.5 centimeters okay one more thing that a question is saying is assume that the object is far away so incoming rays are parallel okay so the rays that are falling on this concave lens they are parallel first let's draw an optical axis for this lens and the rays are parallel like this that is all that the question is telling us along with the focal lens also now this is again a question of image formed by multiple lenses we will be using the thin lens formula so here it is and even in the previous case we devised a sort of a common strategy for approaching these kind of problems for that obviously image that is formed by the first lens that image itself acts as an object for the second lens and then the final image is formed so in this one there are rays that are parallel and they are incident on the concave lens after undergoing refraction they will actually diverge this is a diverging lens and the rays could look somewhat like this they are diverging if we extend them we can have a virtual image being formed at this point so we can we can write this point as the image formed by the first lens and this image itself this image itself acts as an object for the second lens so before we go over there first let's try to find this distance right here this is this is v1 if we are able to figure out v1 we then know that this image formed due to the first lens will act as an object for the second lens we would then get some idea on u2 the object distance and we already know the focal length maybe then we should be able to figure out what the image distance should be so first if we use if we use the thin lens formula once we can write this as 1 upon v1 minus 1 upon u1 that is equal to 1 upon f1 so we need to figure out what v1 is 1 upon v1 this is equal to 1 upon u1 now u1 here is infinity so let's write that infinity plus 1 upon f1 f1 is minus 4 1 upon infinity would be 0 so therefore v1 just becomes equal to minus 4 centimeters this distance right here is 4 and it came out to be minus 4 because if we think about the sign convention this point should be considered as the origin everything on the left hand side would be negative now this image this image acts as an object for the second lens so the object distance for the second lens that is u2 that would be v1 that is 4 plus 0.5 so u2 would be 4 plus 0.5 that is 4.5 centimeters and when we use the thin lens formula again to figure out the image distance that is formed at the retina so let's see how that looks like these light rays after they undergo refraction they converge and the image is formed at the retina this is a distance d that is basically this is really just v2 so let's write that this is 1 upon v2 minus 1 upon u2 now u2 is the distance is 4.5 but it is on the left hand side of the optical center of the lens so we will write we will write minus 4.5 and this is equal to 1 upon f2 that is 2.1 and you can then write this as 1 upon v2 equal to 1 upon 4.5 plus 1 upon 2.1 i encourage you to do that calculation and when you do the calculation the answer that you will get is 3.94 centimeters so this distance right here is 3.94 this is 3.94 centimeters all right you can try more questions from this exercise and if you're watching on youtube do check out the exercise link which is added in the description


My name is Karen Hubbard. I am a senior in interdisciplinary engineering studies with a concentration in pre-medical sciences and I am a black engineer. To be a black engineer to me means to be unbroken. I'm at war every day with my mind, my peers, and my academics. I have to be unbroken every day to not only get the grades but prove my worth to my peers and to my teachers.  Being a black engineer means I have to speak loudly to make sure that I'm heard.   The fact that the minority engineering program exists is my saving grace because I would have definitely transferred to a different school or given up on engineering if I didn't have the minority engineering program. When it comes to how much is put on that office, when it comes to retention, recruitment, graduation, and maintenance of the self-esteem of black students, I think that that's a lot to put on one office and I think that just shows the lack of resource and energy that's going towards making sure that that need is met. So when it comes to things that Purdue could do better at, I think that addressing that these issues of self-efficacy exist is one thing. So acknowledgement is the first thing to, the first step to acknowledging that there is a problem, you need to know it's there. I think that Purdue engineering knows that it's there but doesn't do enough to really address the problem and provide solutions and support and a backbone for black students to fall back on when it comes to the issues that we face in the classroom. The mental health needs of black engineering students are far from just a typical engineering student's needs. When it comes to being the only one in the classroom, I don't have anyone I can talk to that's on the Purdue engineering staff. I have to go to MEP which is in the corner of Armstrong when my classes are halfway across campus. I don't find solace until I step into that room. I sincerely believe that there is some serious work to be done when it comes to supporting us and meeting all of our needs to even just graduate, not only graduate but to be comfortable here. I'm uncomfortable in this space without the minority engineering program. The fact that it closes at five and my staff leaves at five, there's no one to help me after hours when someone in my class picked on me because I'm the only black girl or the teacher gets me confused with some other black girl or black boy again. So I think that having areas of support to really acknowledge and and provide a structure for giving black students what they need is where Purdue engineering administration needs to start. I use my platform through multiple channels and specifically the biggest one that I use is plugging into the mother chapter here of the National Society of Black Engineers. Purdue is a founding chapter of the National Society of Black Engineers where our mission statement is to increase the number of culture responsible black engineers who excel academically, succeed professionally and positively impact the community and I live that mission every single day inside the classroom and outside of the classroom. When it comes to outside of the classroom I make sure that I really help people figure out what sets their soul on fire.  When it comes to how I specifically use my platform I am now chair emeritus of the region four region four of the National Society of Black Engineers which is composed of six regions. When it comes to just my pride for the mother chapter I've actually been a member of the National Society of Black Engineers or NESB for about 10, 10, 11 years now and I only knew about NESB because I was involved in high school and a lot of other students in high school or middle school or elementary aren't really poured into that early. I was just lucky enough to be plugged into a community and have a really strong and vigilant mother who plugged me into these specific channels and made sure that I had a vent made sure that I had a community that was not only grooming me for success but building up my confidence so that I could survive in this college setting. When it comes to my platform specifically I know that I can't do this forever I'm only here for a set amount of years and I am warning people now as I am continuing or getting ready to graduate I'm only going to be here until I graduate and afterwards you're only going to see me in the presence of a check written to the Purdue National Society of Black Engineer chapter. I'm not coming back therefore you have to figure out how to grow on your own how to grow without me and so when I depart from you you're not going to be consistently calling back on me for help. When it comes to making sure that my platform really embraces this lift as we climb mentality that is a huge thing for me so the ways that I use my platform I ensure that I kind of embrace that as well as living and and making sure that I'm a burning light an example for black students to kind of show you that there is hope just when it comes to my own personal journey there are so many tumultuous situations I've been caught up and and just by you know the grace of God and the the grace of just having a community to plug into I survived and I'm going to get my degree and not a lot of people can say that with confidence so with my platform another tip that I'll just also share I really struggle with anxiety and how I turn that around and just kind of reframing how powerful anxiety is and switching that in the opposite direction so if you really think about anxiety it's just imagination in the wrong direction and I consistently teach that to a lot of people who are plugged into me as well as just making sure that my platform my platform just bleeds with this confidence that I wasn't always like this I had to go through a couple opportunities I had to go through a couple of situations where I didn't always have that confidence but I had to I had to build that I had to plug into different people and now that I have those experiences to speak on and I no longer cry when I talk about them it is my platform and that is who I am


When we received our letter of no electricity, I was going to ask for my team to come back and get those higher lights. No electricity. I hope I'll be able to shout. I'm recovering from a bit of a flu. First of all, I found out very quickly last weekend why government officials get new phone lights. The minute they get appointed. I'm sure everybody here had their phones ringing off the hook. I appreciate those who are calling to congratulate me. Extremely humbling. But the majority were calling to ask for work. To ask for jobs. And I could not promise because I have no authority to provide any jobs. But it does frustrate me when I realize we have a sport industry or we should have a sport industry and a sport industry that works would create hundreds of thousands of jobs. First of all, I would say thank you to Waziri. Thank you also to the President. Thank you for this appointment. Thank you to the team. I've been given a really good team. By Saturday evening our WhatsApp group was almost complete. I think one or two people joined yesterday. I knew some of them. I've gotten to know some of them over the last two days. And I believe I have a team that is ready to work. Ready to focus and ready to get this job done. I have been involved for over 15 years in trying to get fans to appreciate our sport. But we keep hearing the same thing. It's not exciting. Quality of the game is not up to par. The infrastructure is not inviting. With the time I remember inviting some girls to come and watch football at Camp Toyoyo. And they said, where would we go? You know? And I had to call in favors just to get, just to hire toilets. Yeah, that's how bad it is when it comes to our infrastructure. So we are hoping that we can close the gap. It's great that we have a grassroot program to develop talent. Because that's where it starts and creating a product that our own people can appreciate. People like asking, why do you watch the English Premier League in European football? Well, the quality is better than ours. It doesn't mean we can't get there. The raw talent, we have it. We are not developing it. So it's great to see that we now have a program that will develop that talent. I have been fortunate enough to travel all over the world. I was at the World Cup in Qatar. I pay for myself. I've been fortunate enough to go to the Premier League, the EPL, the MLS, watch NBA games, rugby sevens in Vegas. And there's a common theme. I'm sure most of you either watched Super Bowl Live or you saw the highlights. The common theme is that you have to create an event around our sport. And that is what is missing, and that's what is keeping a lot of fans away. On Sunday, more people were talking about Rihanna than they were talking about the actual game. I wonder if I asked all of you who won and would be like, we're not sure. If I asked who performed at half time, you don't know. So we need to be able to fuse sport and entertainment to make it attractive for people. We need to get our infrastructure in order. Yes, we do, because that is something that we're very inviting. If you travel around the world, you'll see the infrastructure alone is a sight to see. And it gets you excited about what you're watching. And once you get those three in order, the fans will come and the corporates will be lining from here to Gong saying, my money behind the sport. We're starting football, I can't wait to get to other sports. The federations are calling and asking what's in it for us, what's in it for us. If there is all about football, we will get to football. I don't want to say too much, and like Chulgu said, he's not a politician. I'm really not a politician. That's why I struggle with speeches. So I'll leave it there because I want us to get to work. I want us to get to work. It's a huge task. It's huge undertaking. It's not easy. It's easier to mouth off than to actually do the work. But I've accepted the challenge, my team have accepted the challenge and I think it's time now to get to work. Thank you for listening.


So, one second. Hello, everyone. You should hopefully see my slides. Just before we start, the slides may have taken over all of your screen, but you can resize them so you can see the video at the same time and also ask questions during the talk or type questions while watching the talk. So make sure you make use of that. I'm Christian. I'm a kernel engineer working mostly on the upstream kernel. I also maintain various bits and pieces in the core kernel. And I also maintain and develop Lexi, Lexi, and LexiFS. So Lexi is a container manager, essentially, which can scale up to 10,000 of containers. And we develop the user space site and the kernel space site. So often, we either think about new features that we want on need, I think, would make life for our users easier and then push them upstream, or we run into bugs that we need to fix or that give us ideas for new features. And then we implement them in the upstream kernel, and then we usually make use of them downstream.  It doesn't necessarily have to be a feature that is only relevant for containers, but I usually try to focus on them. And so I'm doing the same this year again. And interestingly, you would think that development stops at some point, but apparently it doesn't really, so that people always come up with new ideas. And these are just some of the highlights I picked out. I could make an endless array of slides where I talk about various kernel features, but this is just a few I'm going to mention here. So let's dive right in. So one of the things that just very recently got added, or one of the things that recently got done is reworking ProcFS. So if everyone remembers ProcFS, I guess, on Linux, it's a Linux dumping ground for, I guess, features and information about the whole system. And it's really a dumping ground. Everybody is adding files to Proc and so on. So obviously, ProcFS has been around for a long time. It's incredibly useful, but it also has a bunch of problems, obviously. So it exposes information about specific processes. It has these ProcPit directories. And under there, you can find, you can read a process memory. You can look at the phytoscripts that the process is open, and so on. You can look at networking information, which is a whole other sub directory, within that directory. But it also exposes system-wide information like ProcCPU info, ProcMem info, ProcStats. And it also exposes what is known as syscuddles. So you can basically tweak the system. You can write, for example, a maximum number of pits that you want to allow in the system, the maximum number of threats that you want to allow in the system, and so on. So it's pretty powerful, actually. But it has a bunch of issues, as I've mentioned. One of the, I guess, gravest issues that we had for a long time is that you essentially only had a single proc mount per pit namespace. Pit namespace is being relevant for containers, obviously. So it means once, so there was an internal proc mount that was created when a new pit namespace was created. And you mounted proc with a specific set of options. These options became the de facto mount options for all instances of proc inside of the pit namespace. Well, that means if you mounted proc again in the same pit namespace but changed the mount option, that mount option would just silently be ignored and not applied. So if you had a proc of this instance in your pit namespace, there was mounted by showing all processes on the system. And you wanted to mount a second proc of this instance. And you specified height pit equals 2, which means hide all of the processes but my own. Then this mount option would be ignored and you would see all processes. That's obviously could lead to security issues. It's just also not very nice in general. It's incorrect behavior. But there were actually reasons why this had, for a long time at least, why this had to be this way. Or at least nobody really bothered going on fixing this. And another issue was the so-called over mount protection that ProcFS has.  And often you don't necessarily want to expose this information to something like a container. This can have two reasons. One, as I said, you can write to some ProcFS files.  So one of the ways you can protect certain files or certain directories if you want to hide information or just not make them accessible. And this is what user space usually does, is over mounting, for example, like a staff null over it or over mounting an empty directory over it, at which point all of the files underneath a given directory disappear. But now the kernel has sort of a problem, right? So if you allow the same file system, in this case, ProcFS or SysFS, to be mounted again, then all of the information that you've hidden under mounts would be exposed. So what the kernel is doing is like, no, no, no. You can't mount the second ProcFS instance because there is a ProcFS instance mounted that is not fully visible, so meaning it has, for example, hidden mounts. So if you wanted to mount another ProcFS, if you want to run nested containers, and you want to hide information from Proc by mounting stuff over certain files or directories, you need to have a fresh, secret copy of ProcFS mounted in order for it to be mounted again. And that was kind of a problem as well. So luckily, someone went through the effort of reworking ProcFS and removed the internal ProcFS mount that was, for example, responsible for mount options not being applied, basically in implementation detail. And that got removed. So now you can have multiple ProcFS instances within the same pit namespace with different mount options applied, which is great, obviously. And now you can have one instance with height pit equals two and one ProcFS instance without it. And a new mount option actually got added. A new security option, I guess, has also been added to ProcFS. Height pit equals P traceable, which means only those processes will be shown in Proc that you can actually P trace, which is pretty good. The over mount protection issue is it's not that the over mount protection issue got removed, obviously, but you can at least mount ProcFS without exposing all of the information that you might not want to expose to the container. This is more of an invasive solution than just over mounting individual files or directories. But you can specify the mount option subset, and then it takes another sub argument, in this case, pit, and it means only mount proc, but only show the proc slash pit directories don't show anything else. That's obviously great that once there was an implementation, this goes a long time back called pitFS. This is actually the implementation of this, but just as a mount option on Proc. So that's great. So you can have multiple ProcFS instances, and you can also mount a restricted view with the restricted version of ProcFS in containers, which is obviously great. But that's hopefully not all we can do with ProcFS in the future. This is not part of the actual patch set right now, if I remember correctly, but this is something that was at least brought up on the list and something that I would like to explore further. So obviously, if you run a container, you often want to expose container-specific information. You don't want to expose system-specific information. So if you look at, usually, containers will make use of C groups, and you will limit the amount of CPUs it can access, the amount of memory it can access. You also might want to show a dedicated uptime based on the init process that the container is running. You might also want to show container-specific load average, which you can also, via complications, calculate from C groups. And so the solution that we've been using for a long, long time, I don't know for how many years, is we've implemented a tiny fuse file system in user space. I've mentioned this right at the beginning of my talk, which is called LXCFS. And what LXCFS is doing, it virtualizes various aspects of Proc. For example, if you start a container and you restrict it to execute on four out of your eight CPUs, LXCFS will be smart enough to hide this in the CPU, to only show those four CPU info CPUs in the CPU info file. And it will also make sure that only four CPUs are listed in your Proc step file. Similar, if you restrict memory for that container, LXCFS will make sure to only show the amount of memory that you actually have available. But it's a user space solution. And while we made it as performant as possible, also via some kernel patches, actually, it's obviously not an ideal solution. It would be nicer if the kernel had the built-in feature virtualizing certain aspects of ProcFS. So this is something I definitely would want to explore in the future. And what we probably also, yep, yep, sorry. OK, I'll just go on. And so this is something I want to explore in the future. So this is hopefully something we can discuss at the Linux Blambos conference, which will take place in August virtually as well. And the idea is that certain ProcFS files, at this point it's unclear which files, but that certain aspects of ProcFS will be virtualized by the kernel relative to a pit namespace, probably relative to C-group information. Obvious candidates, CPU, InfoStat, and MemInf, there might be a bunch more uptime would be cool, and load average would be cool as well. So if at some point we could end up with a partially virtualized ProcFS, that would actually be pretty great. Right, another big feature that landed just recently, which has also been discussed and worked on for a long, long time. So the ProcFS example I mentioned before, like this is not something new, that ProcFS needs some sort of changes to accommodate containers or something that has been discussed for a long time. And similar time namespaces, time namespaces go back at least to 2006 when somebody had a use case for them. But right now they've actually become a reality. So you know that we have seven, most people I would assume, know that we have seven namespaces in Linux so far, pit namespace, secret namespace, user namespace, IPC namespace, UTS namespace, mount namespace, and network namespace. And they all have their uses when building containers, and some of them you might consider essential for containers, and some of them you might think are not essential for containers. But we've added an eight one, actually, an eight one, and this is the time namespace. And it virtualizes clock boot time and clock monotonic. And you might think, well, what's the use case? Well, one of the biggest use cases, and it's actually the people who've also implemented this feature is Crewe, just checkpoint restore and user space, which is used to checkpoint processes and restore them. And also, and by extension there, it's used a lot of container runtime supported to checkpoint a container and for example, move it from one physical host to another physical host, like sending all of the information that Crewe stores on disk over the network to another host and then restoring the process. But that can lead to problems like you can end up in scenarios where for example, if you move the process to another host, suddenly clock monotonic when restoring the process appears to be decreasing and not increasing, which is problematic, obviously, and a bunch of other problems that you can run into. So what the time namespace allows you to do is specify an offset for clock boot time and clock monotonic to account, to make sure that a container sees the correct time or the time that it expects. And currently it's not supported, like all other namespaces are currently supported. You can specify them when creating the container, so you can specify them with the clone syscall. But this is not the case for time namespaces because we've run out of flags in the legacy clone syscall and we haven't settled on the interface for the new clone three syscall, which we've implemented last year. So this is something which we still need to do. So what you need to do right now, you need to unshare a time namespace and then you can write the offsets and then you set an S into the namespace again and then you see you have changed the namespace into with the correct offset set. As I said, it's useful for container migration. One thing I probably should mention because people always keep forgetting this is it just can't currently be used to sync time via NTPD, hopefully I said this right, in a container. So this is what people think about, oh, a time namespace that can run NTPD in the container. No, that's not the case. It was briefly considered, but it wouldn't make the implementation of time namespaces way more complex than what we have right now. Somebody has a good use case for it and is willing to do the work, just probably try all I can see if that gets upstream. You really want to have NTPD inside of a container. But yeah, time namespaces, we have support for it and I'm sure that other container runtimes will pick up time namespaces pretty soon as well. Okay, so this is interesting. This is pretty interesting work. I liked the next two features I'm going to talk about. Both of these features are related to a second Syscall interception. I've talked about yesterday as part of another talk. You all know second, it's a way to restrict Syscalls for a container. You can write complex filters in SecComp using CBPF, classical BPF, so not the BPF that you think I'm talking about, or most people think I'm talking about. It's not EVPF, extended BPF. It's the predecessor, classical BPF. So you can write filters. You can filter Syscalls based on their arguments as long as they're not pointers because for SecComp, all pointers are opaque. And one of the features that we've implemented last year, when I say we, by the way, I mean container people in general, is not that we've done all of this work. We've done a good chunk of a lot of the work I'm talking about here, but I don't want to give the impression that we're the only ones working on this. But given that I maintain a bunch of this stuff upstream in the kernel or help maintaining it. So the sec, we implemented something that extends SecComp's Syscall Interception. So to some extent, SecComp always intercepts Syscall, right? It's you make an entry into the kernel for a given Syscall.  And then it can apply the SecComp filter that you have written and then based whether or not you have a allow or deny list, you, the Syscall might be permitted or might be forbidden, might be skipped and so on. But the thing that we had a problem with is that it's not dynamic in the sense that you can't. So once you've loaded that filter, that filter will always do the same thing for a given Syscall. You cannot change the filter easily while the process is running. So we wanted to make SecComp more flexible so that you can outsource decisions about whether or not a given Syscall is successful to use a space and this is what we implemented with what is called the SecComp Notifier. And the SecComp Notifier is a type of file descriptor and file descriptor for a SecComp filter. So when you start a container and it loads a SecComp filter, you get a file descriptor for that SecComp filter, you can hand off this file descriptor to your container manager process which can put it into an EpoL loop or a general way of getting notifications on a file descriptor from Linux. There are multiple ways how to do this. And then when the container performs a Syscall that the filter is triggering on, notification will be generated that the file descriptor, the SecComp file descriptor is ready for reading and your container manager will get notified and then it can use an IOCTO to read Syscall information. Well, actually a bunch more information but it can read information from that file descriptor. And parse through the Syscall argument, the arguments, the Syscall was given. It can even, if it has been given point arguments, it can go into the PROC PIT mem directory, race free, not going to go into the details and read the memory that the pointer is pointing to. And then it can decide whether or not the Syscall is supposed to be successful. It can even emulate the Syscall in user space so you can, for example, inspect the arguments and you see, oh, it's performing a mount Syscall for something that I'm fine with this container mounting then I could mount this file system for the container and then report back, have the kernel report back to the process that actually, yeah, your mount Syscall succeeded even though it actually should have failed. This is a very powerful mechanism to emulate Syscalls. And again, if you're interested in hearing more about this, I've given a talk about this yesterday so you can rewatch that video probably. But a bunch of Syscalls you can't yet intercept what you might want to intercept. And this involves a whole range of Syscalls that either return, yeah, use phytoscripters. So you get the container manager which has the second phytoscripter for another process gets a notification on this phytoscripter that a certain Syscall has been performed. Think about the connect Syscall. And the connect Syscall takes a socket phytoscripter or socket phytoscripter and an address and then you can connect that socket to somewhere. And it would be really cool if we could somehow bridge the socket connection, right? The container manager sees that the container wants to connect to a certain address but the container manager thinks, well, it might be the address you think you want but actually it's not, I'm going to connect you to something else. But since these are two distinct processes and usually your container manager and your container don't really share the phytoscripter table, that would be kind of weird. You can't really interact with the phytoscripter of that container and also you can't reopen sockets through PROC so that's not an option as well. But what is possible, so we came up with a method to basically retrieve a phytoscripter from another process which wasn't easily possible so far. At least not for all types of phytoscripters. And we added a new Syscall which is called pfd getfd which relates to pfds we'll briefly touch upon a little later but for now it suffices to say it's a phytoscripter for a process that is a stable reference for a process. And so you can specify this and then you can retrieve a phytoscripter from another process in this case for example from your container. It will be blocked anyway because it's waiting for the kernel for Secom to allow it to continue the Syscall. You can retrieve this phytoscripter if it's a socket phytoscripter and you can when you intercept the connect Syscall and then you can connect it to wherever you want that container to be connected to. So you can rewrite incoming connections for a container which is a pretty cool idea. You see that there's a lot of possibilities that this actually opens up. That's something I'm pretty excited about. So it's not something, this might be useful outside of Secom. So this is why in this case we made it a separate Syscall. So a bunch of people have registered interest in this Syscall independent of Secom just getting phytoscripters out of another process. So pdfd getfd allows you to do this as long as you can retrace the target process. And related to this also to Syscall interception again is injecting phytoscripters into a remote process into another process, remote process into another process. So I've talked about connect. You wanna get a phytoscripter connected and be done with it. But sometimes you also have Syscall to return phytoscripters, right? So for example, open, I guess, and a bunch of others, except, and so imagine you're supervising a process and you don't want it to do the open Syscalls itself either because it's so locked down that it couldn't open the files or because you don't want it to have any direct file system access at all. This is I guess a use case and more of in the browser area of things. So you have a broker process which does all of the open calls for you. You wanna inject phytoscripters into a given process. And originally we wanted to make this a separate Syscall as well because we thought, ah, this might be useful but this would have been fundamentally, it would have been very difficult which we figured out in the discussion because Linux has a bunch of close, a bunch of assumptions about how phytoscripter tables how phytoscripter tables work and usually one of the fundamental assumptions is you can only mess with your own phytoscripter tables. So you can only install files into your own phytoscripter table. You can only close files in your own phytoscripter table. This makes things a whole lot easier. And so injecting phytoscripters via a Syscall into another task is actually a bit more involved that you would think it should be or it is. So this is actually a feature that is tied to Second itself. Sargon has worked on this or is working on this and I think it's sitting in Linux next. I could have probably verified this before but I think it's Linux next now. And so what you can do is inject phytoscripters into another task via Second. You can specify, you can even, you can do a bunch of cool things. You cannot just add a phytoscripter into a task. You can also replace a phytoscripter, which is more of a, well, I guess I should, yeah, you can add a phytoscripter to a task and you can also replace a phytoscripter. So you can swap out replacing essentially means the task things phytoscripter four refers to dev console and then you could technically, although this is probably a very bad idea, replace that phytoscripter four and make it refer to some random file on your system. So this is actually a pretty powerful mechanism. And why we did it with Second is I touched upon this because when Second, the way it works is the task can install it into its own phytoscripter, into its own phytoscripter table. This is just how Second works without going into too much detail. So you don't have this whole problem that you need to inject the file or replace a phytoscripter, a file from another task. So Second was actually a natural place to be doing this. So injecting phytoscripters into another process and retrieving a phytoscripter from another process makes this call interceptor feature a bunch more powerful than it initially was. And I'm excited to see what people are going to do with this. We're already using it. I know there's interest from various browsers to replace the current implementation of something similar, like that also moderates, for example, opens its calls for various sub-processes or sub-threads they maintain. So this is going to be exciting work in the future and hopefully we'll have more ideas around this and users around this. Next up, we have something that user space has been doing for a long, long time in a really, in a really hacky way because the kernel didn't provide a method of doing this, which is probably two of a lot of features. So closing multiple phytoscripters at once. I mean, you know that you can only, essentially right now you can close only one phytoscripter per syscall via close. But often when you, for example, exec in your process, you want to make sure that all phytoscripters apart from a few, usually zero, one and two are closed. Or what sometimes system G is doing, it's reordering phytoscripters that the process is supposed to inherit and then you have zero, one, two, three, four, five, something, something. And then that's the phytoscripters that the process is supposed to inherit when it execs and then everything else is supposed to be, it's supposed to be closed. And the way that most of user space implements this via two solutions, as far as I can tell. So either you parse to slash proc, slash self, slash fd, and parse out all of the phytoscripter numbers and call close on them. So you have the cost of parsing through proc and then calling close on all of the individual phytoscripters and you need to repeat this loop in case somebody is injecting or opening new phytoscripters if your phytoscripter table is shared.  That's obviously not ideal. I mean, it's pretty costly. As we all know, hardware bugs have made assist calls significantly faster. Obviously not, but assist calls have become more costly. So closing multiple phytoscripters at the same time would be pretty cool. So this is why we currently in the process of adding a new assist call, it's sitting in Linux next right now, which is called close range. By the way, applications, for example, that close all phytoscripters, I have a need for this is Python. I've seen it in Rust. It used to be in Lipsy. It's not anymore. They removed one of the loops where they needed this.  So in the process of adding a new assist call, close range and close range would allow you to close a whole range of phytoscripters at the same time. And that's done, the kernel does it in one go. It's obviously way more performant. And it also takes a flag. This was also discussed a short while ago.  But close range share is basically doing the same thing. It moves this unshare logic, unsharing the phytoscripter table into the kernel itself, right before it closes all of the phytoscripters and the neat thing also is that it has potentially performance benefits if, because we can only unshare the phytoscripter table up to like, if you unshare a phytoscripter table, if unshares all of your phytoscripters. But for example, if you realize that you're closing everything above a certain, if you're closing all phytoscripters, then you can only unshare up until the lowest boundary and then you don't need to close any of the upper phytoscripters so it potentially has performance benefits. So yeah, I'm pretty excited about this because we are having this loop as well, making sure that we don't inherit phytoscripters. For example, when we fork helper, when we respond helper processes and so on. So we make use of one of the hacky solutions in user space right now. This would be gone with the clone with close ranges call, which is pretty cool. Promise that I was going to mention this briefly. So last year, we introduced a concept that is not specific to Linux. It has implementations on other platforms as well, which is called pitfds. Well, that's the Linux specific name. There are other names on the other platforms, but basically a wish is with pit recycling, whereby if you have a low limit on the number of pits on your system, the default limit used to be for a long time, 32,000 something, and you have a system where a lot of processes are created. You could easily end up in a scenario where the process you're thinking you're interacting with has been recycled, especially if it's not directly a child process. You also couldn't easily observe exit of when another process exited. There were ways around this, but they were really hacky as well. So we introduced a concept of pitfds, which are phytoscripters for processes. So you kind of get a stable private reference on a process, and this allows you to avoid various race conditions because even if that process number is recycled, the pitfds will keep pointing to the original process. You just get ESR switches. Colonel speak for that process doesn't exist anymore if you try to use it. And you can send signals and so on. One of the things that we always thought would be useful and we wanted to do, we wanted to use these pitfds for namespace management as well. Meaning you should be able to pass them to the set an assist column. The set an assist column is quite important because it's used every time you wanna interact with the namespaces the container is using. You need to call open slash proc slash containers pit and s and then for example, user. And then you open a phytoscripter to the username space of the container and then you call set an s on it. And then it switches you to the username space of that container. Now think about it. You need to have this open call and you need to have the set an s call. We're at the point where we're at seven, including the time namespace, we're at eight namespaces. If you don't stash away, if you don't stash away somewhere these namespace by descriptors, you're looking at eight open syscalls and eight set an syscalls. So you're looking at 16 syscalls to change to all of the namespaces of the container at the same time. That's obviously that's an ideal, especially if you think about that some of the namespaces, not a lot, but a few namespaces you can fail to actually attach to. So you could end up in a state where you're half attached to a bunch of namespaces.  Now you're in this weird half state. So we thought, okay, if we could use pit of D, we could also specify multiple namespaces at the same time, and this is what you can actually do. So if you, assuming you have created your container with clone and you have requested that the pit of D be returned to you and the kernel actually supports it, you can use that pit of D and then pass it to the set an syscall and specify all of the namespace flags that you want, clone user, clone UNS and clone UPID and then you get moved into all of the namespaces at the same time, and atomically, which is pretty cool. So if you specify all eight namespaces that the container was spawned with, it will, the kernel will make sure the way we've implemented this is that the kernel will make sure that you succeed in attaching all of those namespaces.  If you fail to attach to any of those namespaces, the kernel will not have altered a single thing.  So this is pretty cool. And obviously, I mean the great advantage, as I said before, it's we're down from 16 syscalls to one syscalls. So that's hopefully pretty helpful. What we still need and what I hopefully will implement soonish is a new flag to all namespaces which are different from your own. So for example, why is this just relevant? If I set an S to a username space of a given container, I have a problem because if that username space is the same as my own, then the kernel will not allow me to attach to the username space so that I can regain privileges, clicking the kernel into giving me more privileges, regaining capabilities essentially. So right now if you specify a bunch of flags and you have calling your user in there, you might fail to attach simply because you're in the same username space. So you need to verify that you're in the same username space first before attaching. So we should simply add a single flag that encompasses basically expresses, move me into all of these namespaces. Yeah, move me into all of these namespaces. That are different from my own. This is future work. And the great thing is that PIDFDs with this become essentially the only token that you need to interact with the container which hopefully makes it a lot easier so no more opening proc and so on. Can also set an S to containers, obviously if you don't have proc mounted. This is hopefully useful. See, this is where we get into the phase where I have a lot more stuff to talk to but I need to cut short. So another feature we added for 5.7 which has also used cases, uses, I mean a lot of the stuff has uses outside of containers but this one specifically is spawning containers directly into C groups. So they often use C groups for resource limitation, right? And resource distribution. And what you usually do is when you start a container you're creating your C group for the container and then you're fork off in your process and then at some point when you're done you move the process into the target C groups actually. People don't realize this involves costly locking in the kernel because you need to take the right side of the C group semaphore that is costly and it also can, well, obviously people realize that it can cause accounting jitters. So there is a time where that process lives in the same C group as the parent process and uses resources from this C group rather than from its target C group. That's usually not a big thing but if you're into accounting, into accounting then this is kind of annoying. So we thought, well, it would be kind of cool if you had a new flag that you could set during with the new clone three system call and then also specify the target C group that you want this process to be created in. And this is what we added in 5.7. So you can set the clone into C group flag with clone three and you can also specify the target C group. You want to be moved into the caveat is it only works with the unified C group. Why? Well, because unified C groups there is only a single hierarchy in contrast to the legacy C groups where the convention was that each controller like memory CPU set and CPU was mounted into a separate hierarchy and unified C groups are the future anyway. So we thought this is the way to go. So you take a unified C group file descriptor which is your target C group and then the container gets spawned directly in the target C group. There won't live in the parent C group for any amount of time. We'll get created right in the target C group and you don't need to take this costly write semaphore lock for C groups. So if you spawn a lot, a lot of containers this is actually cheaper. Other use cases we recently thought might be useful is right now there's a patch set which is called core scheduling which is up in Linux on the discussion which was originally thought to target some of the new exploits, MDS exploits that we have seen, LT of one and so on by making sure that processes only get scheduled on a specific core. So they can't attack each other. It's kind of funny because we've probably some people have read the paper about crosstalk which kind of proved that even with these scheduling strategies you will still have issues but it's still a kind of a nice idea. And if it's going to be C group based which is at least one of the approaches that is going to be discussed you can create processes right into your target scheduling C group which is pretty nice for this use case as well. There's a bunch of other stuff that I have I just want to briefly mention before I close and open up four questions is we have, we want to do shift effects at some point this is still up for discussion we have multiple patches that we kind of need to converge and come up with an upstream solution for this so this is still not forgotten it's just that it takes long. We had briefly a discussion about loopFS which makes loop devices available in container we will see if this is going to go anywhere or if we end up with a different solution. And we also will probably come up with a new syscall to change in the new mount API to recursively change mount attributes on a bunch of mount points. But for now this is a bunch of features I thought were worth mentioning there's a ton more. The only thing that helps figuring out which are interesting for use cases is go look at the kernel. And otherwise I hope I could give you an update of what is happening in container kernel land. And so hit me with questions. So I'm just, if it's probably fine if I'm going to read them out loud so what protections are in place to limit access to PITFD, KTFD? Well, first of all it's skated by Ptrace may access so you can only get a file descriptor from another part process if you have if you can Ptrace that process. Because if you have Ptrace access you can in hacky ways and convoluted ways you can already do this. So Cree is essentially doing something or at least used to do something similar with what they call parasite code injection. It's not my phrasing, it's Cree's phrasing. But so you can already do this with Ptrace but it's very nasty and very hacky. So the check right now is if you can Ptrace the target task you can retrieve a file descriptor to it. If you're worried about, I'm going to stop the screen channel. If you're worried about the syscall in general probably second. Can sadness manipulate syscall as an array? I'm not quite sure what this means but I'm going to guess that you mean if you can attach to multiple names basis at once and then I'm going to say yes but otherwise I'm not sure I understand the question. What does the API to inject FD to another process look like? So it's going to be second based. The current proposal that we have it's going to be a new IOCTL on. So the second notify a file descriptor that I briefly mentioned has a bunch of IOCTLs on it. So one of the IOCTLs is read and another one lets you redistruct from that file descriptor. Another one lets you write to the kernel. And add FD would basically be another IOCTL where you could specify a struct that contains a file descriptor that you have opened and then you can specify I want this file descriptor to be injected into the target task or replaced. So it's under discussion, as I said it's under discussion upstream. And for the permission it's guarded by security file receive I believe as well. So it should also be guarded by ptrace I think. I need to verify this again before I'm telling you nonces I haven't looked at this patch in a while. What more complexity would be required to run NTPD and Lexi Lexi? Well, you would need to extend the time namespace to support a way more advanced of what time namespaces do right now. So actually kernel work would be involved. Well, that depends. You can run NTPD in the container right now you just can sync time inside of a container because that aspect is not virtualized. So it's possible to run NTPD it's just not possible to use certain features of NTPD I'm no expert on this. Will the C group have the same accesses of resources once it's passed into the target? So I can briefly reiterate how this works. So you specify the file descriptor for the target C group presumably what I would advise if you create that C group you set up the limits that you probably want or you move the process in there and then apply the limits, the order is up to you I think with the new unified C group as well. And then the process is restricted right from the start. So that's the idea of how this will work. So the idea is you don't have a scenario whether the process is for a certain for a really tiny short amount of time before you move it somewhere unrestricted. It's basically restricted. If it spawned and that C group has some sort of limit set up then that process is restricted right away. The limit at the permissions if that's another part of that question the permissions are the same for when you want to move a task into another C group. So it's the same permission checking that would take place when you were to try to write a pit to a target C group. Same permission check supply for when you spawn a process directly into a C group. If you don't have permissions to spawn a process in that C group, then your process creation fails. Yeah, so when I think with that I'm out of time I hope you found this useful. There will be around in this slack channel thingy. So you can ask a bunch more questions right there if you want. Otherwise, if you have more questions you can always write me a mail. I don't promise to respond, but I try to. So thanks. Bye.