Okay, the recording is on, we'll pray and get started. Who would like to pray? The mic. Okay, Chirah, you can pray. Connect them. Okay. Thank you. Holy Father, we thank you for this wonderful morning. Lord Jesus, thank you for your grace, mercy, you know all right, my Father. As we are in class, my Father, give us understanding. Give us your understanding that we can understand whatever the message is as my Father. Help us to learn from you, my Father. Lord, help us to know about you more and more, Lord Jesus. Thank you, God, that we all are here alive, my Father Lord. Thank you for everything that you did, my Father Lord. Yes, Lord, we are learning because of you and for you, my Father. Thank you for everything, Lord. In the name of Jesus, we pray. Amen, amen, amen. And thank you. Thank you, Chirah. We will continue in our sessions. So please turn to chapter 17. So far, I hope that you have enjoyed what you have learned, but more importantly, apply. I know that some things may have been new, whereas some things may have been part of your life already, but you could strengthen yourself in what you already have been practicing and apply all the new things. So I really hope that this class has been a blessing to us. And as I've been saying, we'll complete as much as we can. And hopefully, we should be able to be done with the entire portions. But if we are not, I will do an additional recording which you can look at, listen to and learn from it. So today, we are going to talk about praying for praying over cities, regions, and nations. So far, we've learned about the fact that one can pray personally and develop their personal prayer life, but we also saw that intercession is possible. Intercession is to pray for others. While we pray for family members and church members, we see in scripture that God has a heart for places. So when I say places, it's cities, it's regions, it's nations even. And so when we pray for an entire city or an entire nation, it's very biblical. So as you look at the scriptures, you would see particularly in the Old Testament when God looks at a city and calls a city by name. So he doesn't address the city as, okay, different sections of people, different communities of people, but he just says, oh, Jerusalem. So what's happening? There is an identity which that group of people or the communities which are knit together have as a city. So you hear names like that. You hear Babylon, Babylon shall fall. So we recognize that God identifies an entire city and that he has an interest in these cities. Think about Sodom and Gomorrah. You know, Sodom and Gomorrah was going to be destroyed because of their sinful lifestyle, but we see Abraham interceding for Sodom and Gomorrah and God actually engages with Abraham. Interestingly, like why would he be, why would he make the time to listen to Abraham when he says, okay, if there are so many righteous people, would you spare, would you spare? So God gives an opportunity to people so that they can, if they can present something or intercede, he will actually relent or he will stop from pouring out his wrath on the people. So that just shows that he is interested. He does not want to punish, but since there is no option, you know, sin has consequences. So he will have to go ahead and punish the people. So Sodom and Gomorrah, even a sinful city, God was actually giving them that space and saying, okay, if there are righteous people, yeah, maybe, maybe I can spare this place. Okay, and yes, Abraham, you can talk to me about this. So God loves cities.  He went to Tarshish, but God had an intention for the sinful people, right? If they don't hear about God, if they don't repent, then how is it that they can be, you know, how is it that they can be spared? So somebody had to take a message and that was Jonah. Though he wanted to escape, God didn't let him. And even there, he preached, right? He preached the message and the people actually repented. So what is the outcome? Again, God relents. See, God, though we see that cities are sinful and there are consequences, God is actually waiting for his purpose for every city to be accomplished and which is a good purpose. He wants them to be prosperous. He wants them to be blessed. So when Nineveh repented, what did God do? He had told Jonah, you know, I'll do this, I'll do that. And that's what he preached. But God didn't punish the people. So Jonah was so upset.  He says, look you are so upset about a plant which you never, you didn't make it. You didn't nurture it and you're so upset that it died.  And why should I destroy them? You know, if they repent. So in all this, we're just understanding that God is waiting for people to respond. And when they do, his purposes will be accomplished in cities and nations, even Jerusalem. You know, there are many scriptures. I'm not going through the scriptures because it's in your notes. You can always go and meditate on them. He calls out to Jerusalem, cries out to Jerusalem. In Luke 19, there is a passage where he says, oh, Jerusalem, if you only knew the day of visitation or the fact that I'm working within you, but you're not realizing it. As a city, the people did not realize that God was at work, okay? So this is how God actually looks at nations. And we are instructed to intercede for the nations. In Jeremiah 29, verse seven, there's a very important scripture it says, pray for the peace of the city where I have planted you, where I have, you know, established you. Because in its peace, you will have peace. So one way of looking at this is, we as believers carry spiritual authority to speak blessings, peace, justice, prosperity, whatever, everything that is available in scripture, we can declare it over our city. Will it work? It's got to work because that is the reason God is saying, I want you to pray for your city. What if we don't pray for the city? What do you think? Okay, fine, it's an option, but maybe I won't pray for the city. What will happen? Situation might go worse. Okay, why would it go worse? Because nobody is praying, okay? So if we pray, what is the difference that it's gonna make? Okay, so the purpose of God will come to pass when we pray for the city, okay? So what else? Purpose of God will come to pass. What are we actually doing when we are praying? And what will happen if that prayer is not there for a city? Okay, spiritual warfare, we'll come to that. Yeah, we are using our authority against the demonic powers, that's true. What else? Okay, like prophetic prayer, right? So you pray into certain things, which let's say, God has already revealed. And then when you pray, those things are, you know, averted. So yeah, that's correct. You can, so protection, right? Through your prayers, there's protection over the city. Through your prayers, there can be demonic, you can go against the demonic powers, you can speak the purpose of God, yes? Yeah, so the way we saw last week, praying for the lost. So when we pray, people can actually open their hearts to the Lord Jesus, and they can also receive salvation, okay? Okay, what if we don't pray? Nobody's praying for the city, what will happen? Spiritually, what might happen? Deep will be in chaos. Why will the city be in chaos, I'm asking you? Okay, okay, so there's no one praying, nobody to declare the power of God over the city. That's correct. See, you can look at it this way. Imagine that, you know, a house, or let's say your campus here, that is the city, okay? Now, if there are certain things which are not done for this campus, it is at danger, right? And we already know that the world is corrupted with sin.  And he is very active in causing destruction. So whether you like it or not, he will take the initiative to destroy everything that God has created. What if there was no fence? What if there were no documents to say that this belonged to a certain person? What if there were no people to maintain this place, right? Basically, intrusion, intrusion, destruction, calamity, all those things are what Satan and his demons do. So when we don't protect, or when we don't understand, you know, what is its original purpose? We are allowing it to be destroyed, even though God intends good, right? So maybe this place is supposed to be used to equip people in the world and to spend times in worship, experience the presence. So many wonderful things are there. But someone has to take charge to say, hey, this place is for this. And we have to stop the intruders. What if you keep the gate open all the time and you didn't have a watchman? Anybody will come. Anybody will do whatever they want. When they will pick up stuff from your equipment from here, you can ask them, because we are doing nothing to preserve the place or ensure that the place is functional the way it was intended to function. Something similar is expected when we don't pray for the city. We're just letting it pass by. We have an active enemy. He can do whatever he wants. And then we complain. We say, oh, look at the city. It's such a sinful city. There's so much crime in the city. And leaders are not making good decisions. But we understand these are the facts. However, there is a responsibility which a believer has towards the city. When we don't do our part, we are keeping an open door for the enemy in a sense. So which is why we should never let that happen. We have a responsibility and we have to pray for the city. Or we always say, stand in the gap, stand in the gap between the people and God. And whatever has been provided by God for the city, by faith, you take it and you will see those things happening. So that is how you understand praying for the city. So God is very interested. God is very interested. There are scriptures that say, if God's people pray, you know, Second Chronicles 714, many of you would have heard if my people who are called by my name, they would humble themselves and pray. If they would turn from the wicked ways, I will hear from heaven and I will heal their land. So God is saying, if you come sincerely, humbly and you pray for your own land, I am going to heal it, no matter what condition it is in. And God is also responsible for the rise and fall of nations. Okay, this is simply the way we understand this is, though there are leaders in authority, when we pray, right, God can move, God can move, God can move in a sovereign way. He can determine, you know, the establishing of a place or a nation or he can determine the fall of a nation. So when you read about kings like Nebuchadnezzar and all, so you'd see there, you know, how it worked, a Cyrus. So the way God actually worked, even though there were some mighty nations in those days, empires fell and so many things happened. So at 1726, it says God is involved in the rise and fall of the nations even, not just cities, but nations. So since God is so interested, we must realize that, you know, we have to do what is required as believers. So we'll just look at a couple of other things that, you know, we see in the word of God. There are cities that experienced God's blessings in scripture. There are cities which were disobedient to God, which, you know, received even prophecies, like you will be destroyed, isn't it? So prophets used to prophesy over cities. These things are seen in the Old Testament. We also see that there are, as one of you pointed out, demonic strongholds over cities. It's nothing new. You know, whenever we read about believers authority and like demonology, the subject is there in your next semester. I think we have to look at it in a very, you know, like from a place, I would say from the cross. So it's only when you read only about, you know, and demonology that we get very intimidated and think, oh my goodness, how are we going to deal with all this? But when we understand our position in Christ and we understand what Jesus has done through the cross of Calvary, we will look at all these, you know, activities of the devil as things which we can overcome. So when we study, like in the book of Daniel, there is an incident in Daniel 10 where Daniel is praying, but the answer to the prayer doesn't come because there are principalities, okay? In the spiritual realm, which are a hindrance for the prayer, right? But when you read about what kind of principalities are there, it says the prince of Persia and the prince of Greece, right? Prince of Persia, prince of Greece. So who are these prince of Persia, prince of Greece? You see in Ephesians 6, Paul talks about it. He says principalities, you know, powers, spirits of wickedness. So there is something like an hierarchy of demons. Among those demons, principalities, we can understand that they are probably in charge of large regions, okay? So prince of Persia means there is a demonic entity which works on, you know, destruction of Persia. So every nation there is, every city there is, okay? We can come to this conclusion that there are demons which are corresponding to, you know, every city, every place because the way God's intention is to bless and prosper, what is Satan's intention? We got to destroy. And he is very, very intentional. He's very intentional on doing that. So there is the prince of Greece and the prince of Persia. It just tells us that when we pray for cities, remember when we said we are praying for the lost? What was another aspect there? I said prayer is important, plus one more thing is important, what is that? Yeah, they have to make their own decision, but prayer and love, okay? Fasting, faith, okay? You're all correct, but I'm trying to get that one word. Declaration, okay? Okay, someone's away from God, okay? And you're preaching to them, you're praying for them. What else do you have to do in the spiritual realm? Warfare, okay? So correct, what you all are saying is correct, but spiritual warfare is what is expected. Same thing when it comes to cities. Why spiritual warfare? Yeah, it's so clear. There are demonic powers which are engaged to destroy the cities. See, God has a good purpose always, but there is the demonic realm. So prayer is one thing, but part of prayer has to be spiritual warfare, okay? So keep that in mind whenever we are praying for cities, nations, regions, there is this additional aspect, spiritual warfare, because we're also using our authority against demonic powers, okay? So that's how it works. So remember this, while praying for the lost and also while praying for cities. So as a church, I've been saying, we must look at demonic powers from the place of the victory of the cross. What did Jesus say in Matthew 16, versus 18, 19, he said, you know, I give you the keys of the kingdom. So we have the authority, we have the authority and in the works of Jesus, you would notice that he never gave, you know, a little bit of room for demonic strongholds. The moment he recognized that people are being oppressed by demon spirits, he immediately cast it out, right? So that kind of urgency he had because he knew that he carried the authority. You know, we, if we don't understand that yes, we have been given this form of authority, people also linger and say, okay, you know, we'll deal with it slowly. Oh, I'm so scared. Why? Because God's people are perishing for lack of knowledge. Our knowledge is I already have the authority, right? And I have the keys of the kingdom. I have the authority to bind and lose. Okay, what kind of spirits are operational? Remember, we talked about spiritual mapping. In the spiritual mapping, we said, maybe there is a strife, maybe there is violence, maybe there is alcoholism, you know, some kind of a specialized way in which the demons are affecting the people. I can bind it, okay? And whenever we're praying for cities and nations, regions, another very important thing is, it is good to pray collectively. Can I pray alone? Yes, we can pray, there's no problem. But it is more effective when we are all in agreement in prayer. So, we usually say, a city-wide battle is one through city-wide prayer. So when I say city-wide prayer, it will also mean that not just one local church, see one local church is not good enough for us to fight for the city. Will God do? Yes, He will do because we see in passages of scripture that God is looking for one man, there was nobody, you know, Isaiah 59, 916, Ezekiel 22, 2931, one man to stand in the gap. So one man is good enough, actually, but there is something about the prayer of unity. And so, if church is in a city, okay, when I say unity, there can be a lot of differences. You know, we pray like this, they pray like that, you know, we sing like this, they sing like that. We can have all our differences, but when we are born again, okay, we are part of the kingdom of God, we can unite our hearts to bless the city, okay? That's very important. So we have to maintain that unity. We will talk next semester, we will talk about this teaching called the kingdom of God and the kingdom of God does not necessarily mean one local church. Yes, one local church is part of it, but we are all part of the kingdom, right? So with that understanding, when the believers, the leaders, right, all the pastors, everyone with one heart, we pray for our city, it's very powerful. You got it? And which is why we must also maintain that sense of brotherly love for others, just because I do ministry differently, doesn't mean that I don't relate rightly with somebody else who does ministry. So a city-wide battle can only be one with city-wide prayer and for that, you need oneness of heart. We may, it's good, there are some cities where people have come together, all the churches have come together. Some of you may have heard of, which one? Oneness, yeah. Are you talking about any particular city? Okay, oneness, okay, he said oneness. No, I was getting the name of this place. I think it's called Kali in Argentina, if I'm not wrong. And a few years ago, there was a video which they released, a video and a documentary where they talked about how churches of the city gathered in auditoriums, so they used to come together and they used to pray, they used to have this all-night worship and from that documentary, in that documentary, they recorded that there were certain things which were happening in that city, like there was a lot of peddling of drugs. There was murder, violence, gun shoot, people getting shot on the roads, crazy stuff was going on. But when the churches of the city started coming and praying like this, there was a marked change in the atmosphere of the city. You get it? So just a simple example, you can also Google it, you will find the documentary on YouTube, they put it up on YouTube. But how did it happen? I'm sure there are many examples that we will also study about revivals. In revivals also, there are many examples of people coming together, believers coming together, churches coming together and praying together, which blesses the city. But just something for you to visualize. And in this particular, I think the video is called Transformations, if you search for it. You will also notice that they not only talk about falling of crime rates, but they also saw that the produce from farming was something really amazing, that particular year. The farmers, they did their regular stuff and when they harvested, apparently the vegetables and stuff that they got out were huge, compared to any other time when they have harvested, stuff over there and they were attributing it to the prayer and the blessing of the believers over the city. So I'm just giving you one example, you can look it up, it's very inspiring. So in this way, we must recognize that we are here with authority as believers. The cross of Jesus has destroyed the devil 2000 years ago. We are here to enforce our victory. Wherever we go, we have to take charge. What did Jesus teach in the Lord's prayer? Matthew 610, he said, pray like this, thy kingdom come. When we see evil, that's not the kingdom of God, but when we see righteousness, when we see justice, we see peace, we see God's love, we see God's restoration, his redemption, that is the kingdom of God. As believers, that's what we are saying, Lord, let your kingdom come. Let the enemy leave this place and let your kingdom be established in every city. Let your kingdom be established in my city. That's how we must actually pray for our cities. So a couple of more things that we can begin to understand about the city. I already said God has a plan. So God has a purpose. When God talks about Jerusalem, he says, you would see the prophecy that God intended for Jerusalem to be a joy, you know, a city of joy, okay? So that way, every city God has a dream. We have to pray and ask God, like, God, what do you want my city to be? What is your word for my city? When we know what God's word is for our city, we must begin to pray. Like, okay, God, this is your intention. I bless this city.  Unfortunately, though God has a plan and a purpose, what did I say? In Psalm 48, it says, verses 1 and 2, that God intended for Jerusalem to be joy, okay, a city of joy. But what is happening now? What kind of a place is it? It's ridden by a lot of conflict. It's, you know, ridden by, like, political battles. So many challenges. God's original intention is something, but something else is going on. So you see, there is a battle. We have to engage in this battle. Unless believers pray, Satan is very happy to make every city a seat of destruction, okay? So we even see in Revelation, God talks about a particular city called Pergamos. I don't know if you've heard about this, but Revelation 2, verses 12 to 13, it says that Pergamos is the seat of Satan. So can a city become a seat of Satan means what? If he's sitting in a city, it means he's ruling there. He's reigning there. You can find all kinds of evil if a city is the seat of Satan, right? So it just goes to show us that if we don't take charge, like I gave you the example, this building, this campus, if we don't take charge, if we don't, you know, state claim, hey, the papers say it's ours. You know, you intruders, you cannot come inside. If we don't construct, you know, the walls and the gate and have a watchman and all that, somebody will come, somebody will take over and they will state claim. So that's what it says. Pergamos has become the seat of Satan. He does whatever he wants in Pergamos, but we should not let it happen. And today, as we notice, you know, all, so many cities in the world, we could say lot of challenges. Isn't it? What kind of challenges do you see in cities? Drugs, okay? Someone said drugs. Sorry? Politics. I can't hear you. Political issues. Corruption. Corruption, political. Okay, political challenges. Okay, that's right. What else? What else do you see? Yeah. Injustice. Witchcraft. Witchcraft, okay. Murder, violence. So what are those works? Demonic works are there. We agree. But what kind of works do we see? Suicide, yes. Suicide, untimely death. Addiction. Conflicts, yeah. Between communities, communal disharmony. Yeah, that's true. Hatred. Yeah. Communal disharmony.  Yeah, rape, injustice against women, children, elderly. Greed, yeah, greed. Greed is there. Lack of infrastructure, poverty. You see? So, you know, in the cross, there is righteousness. There is justice. Okay, there is God's love to restore. There is abundant life. Jesus said, I've come that you may have life and have it more abundantly. So what is our intention when we pray for the city? We are seeking the blessings of God and saying, God, let all this evil be replaced by your goodness. You rule and reign. When you say, thy kingdom come, it's not talking any political thing. No, not at all. We could have people of some other faith and office. No problem. But as believers, we have been given this responsibility and authority to bless our city, right? All we are saying is, God, let all these evil things be removed. Let your rule and reign, which is the rule and reign of love, justice, power, let everything come. So that's how we go about it. But when God sees sin in the city, what do you think happens to him? How does God respond to sin? He's closing his eyes. Yeah, okay. And everything happened, let everything happen. You think he's closing his eyes? No. How? Okay, give me scripture. If you're saying something, tell me why. He's not closing his eyes. Substantiate. Tell me why. He loves his people. Okay, where in the scriptures have you seen that God is responding to sin? What did he do when he saw sin? Some examples, you tell me. Okay, someone here says it grieves his heart. Okay, I agree with you. It grieves his heart. Prove it to me. Jesus. Correct. So he looks at Jerusalem and says, you didn't recognize your day of visitation? Oh, Jerusalem. He weeps over Jerusalem. He's grieving. Okay, so that makes sense. What else when he sees sin? Angry? True? Sodom and Gomorrah, very good.  This is how you should talk. When you say something, you should say, where is it? You know? Okay, he was angry. God gets angry when he sees sin. Example, Sodom and Gomorrah, very good. Give me one more example. Ninna way, very good. So when he saw sin, what did he do? Correct. So he knew the consequence, but he made a way for people to respond. Right?  So you see, by scripture, we can understand, okay, this is how God works when he sees sins in a city. So we can imagine now, okay, this is how God must be thinking about. You can think Bangalore, some of us are from Bangalore, some of us are from, you know, some of the cities, what are the cities you're from? And maybe here also, in our chat, if you can type your cities, that will be good. Which cities are we all from? Okay, Assam city, Tensukia, okay. That's a new name for me to pronounce. Then Uttarakhand, Dehradun, UP, Farukabad, okay, Farukabad. See, so many cities. Yeah, Bangalore, Bangalore, Kolkata, Francis, Toronto? If you don't talk properly, I can't hear you. Trivandrum, okay. Francis is from Trivandrum. Guntur, Andhra, I know, where in Andhra? Vijaywada, okay, Vijaywada. Bhima Varam, okay, nice to hear. You know all the city's names. Okay, we have people from, here you have Kohima, Oh, Moroto city in Uganda. We have Belgam, very nice. See, all of us are from so many different cities and God is looking at each one of us for those cities. Right, and he's saying, you carry the authority, you can bless, you can declare God's kingdom here. Don't let the devil play his havoc. You know how it says about Purgamos that the seat of Satan is in the city of Purgamos. We don't want that. Instead, even if there's one person, like, you know, Isaiah 59 verse 16, God was looking for one person. He was wondering, is there one person to pray for the city? We can be that one person. But of course, if we make an effort to have the unity of heart and pray together as believers in a city, we can see a change and a transformation. Okay, there's more people sharing here, Salem. Okay, we have someone from Salem. That's nice. Nice to see. Okay, so the body of Christ can shift the balance in the city. And I gave you that example of transformation. You know what is the Bible call us? Here at APC, every Sunday you hear salt and light. Salt and light. We have a job to do. No, we're not just here to, I mean, of course, we have a blessed life in Christ, but there is a mandate, okay? And there is work to do. And that's why God is equipping us also because we can do it. He has called us to do it. He has empowered us to do it. And we are the salt and light, the churches in a city, the leaders of the city. When we gather together, just begin to pray, things will change, right? Some of us will say, oh, what is the point? Only prayer. Somebody has to do other things also. No, like just if you take, for example, pollution and the city is so dirty, there's plastic everywhere. What is the use? Some people say, working hands are better than praying lips. Somebody said, in your mind, you thought, how prophetic? No, but you see, we understand that. Action is important. You're not saying action is not important, but the first step, you begin with prayer. I'm sure God will give us more ideas on what we can do to swing into action about issues. So God will lead us. But first step is begin to pray. And moreover, that was just a quote. It's not a Bible verse. In case you try to search in Bible gateway or something, it's not a verse. All right, moving on. So we have to be like watchmen for the city. In the olden times, they had watchmen who would stand on the, they had city walls. You remember Jericho? Walls, fortress. So these watchmen will stand and they will stand and they will look into the distance. That was their job, day and night. Why? Because they are looking and seeing. Is there any attack coming on the city? If there is, they have to immediately alert the military or is there a messenger? In those days, they would also have messengers. They'll come with some good news. They'll come running with some good news or they'll come running with some bad news. So that was the job of the watchmen. Stand and be alert. You know what the Bible says in Isaiah 62 verses six and seven, it says, God has set watchmen for Jerusalem. Who, it says, watchmen don't give God any rest. In other words, what God is saying is there are people that God wants to engage in prayer. When we pray, though we are not standing on any city walls, spiritually what are we doing? It's like that. We are watching over the city. We are praying, we are watchmen over the city. So when we pray for the city, imagine yourself like a watchman in the spiritual realm. There are things that may come towards the city which are saying, stop, go back. But there are doors that you can open and say, thy kingdom come, let blessing come, let prosperity come, let joy, justice, let it come into my city. So we are watchmen and our duty is to pray. Spiritual watchmen, what do they do? They pray and that is what God says. We are as watchmen, we are here to protect. We are here to open and close the gates. We are here to maintain or preserve. We are also here to observe many things. So it's basically something like shepherd. The shepherd takes care of the sheep, isn't it? So similarly, when we pray in a sense, we are shepherding, we are protecting the city. We are nurturing the city. Okay, so that's our job as warriors and intercessors. So take time to pray for the city. In our notes, there is an entire list which you can use to pray. I'm not gonna go through it. It says, you know, we can pray for the city-wide church. That's one of the prayer points. Always pray that when I say the church in the city, I don't mean, you know, grace church, love church, faith church, no, all the churches together. Spiritually, when God sees the city, he sees the church of Bangalore. So in that church of Bangalore, APC is just one church. But the church of Bangalore is the believers, you know, the leaders that God has raised up in the city. He sees like that. So we should pray, Lord, let the church of Bangalore be strong, may it be enriched. Same way, you can pray for your own cities, all the names we saw, let the church of Belgaum, let the church of Salem, it's a spiritual thing. You know, we're praying for strength. Pray for every city, let the church of that city be strong in the name of Jesus. Not raise up, equip them with the power of God we demonstrated. So that is one prayer point, which we can pray. Then of course, we can pray that, you know, let the church be a place of your presence, let it be salt and light. And then, you know, we could pray for things like repenting on behalf of the city. I'll just give you two, three points remaining you can see. One is pray for the city, city by church. Second is repentance. Now, there is something in the word of God where though we have not done it, we can pray with identification. We call it identification, okay? I'm not gonna stop, just give me one minute. And then only I'll stop. So identification where someone has sinned and we are praying as if we have sinned. Like our sorrow is as if we have done, that is called identification. So we can repent on behalf of the city. Did we sin? No, but the sorrow we carry helps us pray prayers like God forgive us. So the church can repent on behalf of the city.  So we can pray prayers of repentance. Then of course, we can pray God, let there be a revival. I will talk about it later in detail. There are many prayers here, which we can pray for revival, pray for peace, pray for all the issues, pollution, marriages, families, young people, corruption, injustice, dignity of women, orphan, unemployed, people in the prison, so many things are there. God puts it on your heart, best is make a list. Then you will be able to pray for everything. And of course, engage in spiritual warfare. How do we engage in spiritual warfare? Just go about doing things that God has called us to do, the way you see in the book of Acts. Peter went, he cast out demons, he healed people. Similarly, Paul went, he did the same thing. You see, entire cities turning around, city of Philippi, city of Ephesus, city of Corinth, there was a huge impact because they went and demonstrated the power of the Holy Spirit. So with that, we have finished this chapter. You can take a break. We will restart at 10 or two, okay? So you can take those two minutes also, see you soon. Thank you. Okay, online students, if you have any doubts, please do post it on the chat and I'll do my best to answer it. So yeah, we'll have a break. Thank you.


So apologies for being a bit discombobulated today. OK, so you're good? OK. So what we're going to do today, welcome back. Thank you guys. Oh, this is the group that's taking the class. Today's the drop deadline. So today what we're going to try to accomplish is we're going to finish some of the examples we started last time using simple Linux utilities to sort of poke around and find out some details about running processes. Do you have a question? Yeah, can I get to that in a sec? Sweet. And then we're going to start talking about the process life cycle. So where do processes come from? How do processes change? And where do processes go? Question, yeah. OK, great question for Piazza. Question about script. Can you post it on Piazza? Sweet, thanks. All right, so yes, today is the drop deadline. Recitations will start this week. I think the first recitation is when, Wednesday? Is that true? Tomorrow, Tuesday, all right. And then we have the glorious Thursday 8 AM recitation. Friday, even better, Friday 8 AM, yeah, fantastic. So if you're still looking for a partner, how many people don't have a partner for the class? All right, so yeah, I know. How many people are not a ninja and don't have a partner for the class? OK, a couple of you guys, please come by. If you want to look for a partner in person, come by Davis Hall today for office hours after class, which start at 3.30. And we will try to help you find some, right? Or talk to you about other options, OK? It's crunch time. If you guys don't have a partner, haven't gotten started, then we need to get choked up as quickly as possible. So come to office hours today, and we will help. All right, so just let me make a, you know, now that we've maybe potentially scared away a few people, let me talk about grading, right? I didn't want to talk about this earlier because I was afraid I would scare away more people. Just kidding. Actually, so my goal in the class is for everyone to do well. I don't have a quota as far as how many A grades I give out. There's not a limit. It's not a limited resource. I can actually give out as many A grades as I want, right? And I want to give you guys all an A. That would be fantastic, right? If that ever happens, I will email the faculty list and brag about it, right? And maybe I will get in trouble, but that's OK. That's really what I want to do. I want you guys to all get to the point where I feel like I can give you an A grade. In this class, that grade means something to me. It means something to people who know me. It means something to people who hire our graduates, graduates of this class. So it's not a meaningless grade. It's not something I can do just by waving my hands. But I don't have any rules about how we grade the course. If you guys do well, if everybody does well, you'll all get a good grade. It's that simple. And we're going to do as much as we can to try to help you with that. If you have any questions, use the forums, or particularly about grading. Or email us if you have technical administrative questions about how grades adds up. Most of that stuff is pretty well covered on the syllabus. But again, this is not a cutthroat course. I want you guys to do well. We're going to give you as many resources as we can to make sure that happens. And the rest is up to you. So I try to, the way I feel good about asking you guys to do this much work is by putting resources at your disposal to help you. So please step forward and do the rest. The what? We've made it through three classes before someone asked about the lecture slides. So yes, the lecture slides will be posted on the official course website. If you go back and look through the videos, I've said this every year. And before they were up on the old website, that old website is down. Finally, I got tired of paying GoDaddy for it. So that is down. And the new slides will be up in the next week or two. We'll certainly have them up in plenty of time for the midterm. Does that sound reasonable? They're so close. I just have a little more hacking to do to get them up there in a nice way that I feel good about. OK. So last time, what do we do? We started talking about process, the process abstraction. And if you guys are feeling a little bit confused, I understand that. There's a certain degree of circularity to some of these concepts, especially when we're getting going. So just bear with us. Because processes in particular depend on these other abstractions that we haven't talked about. But I think processes are the most natural starting point when we start looking at what the operating system looks like from the perspective of user programs that rely on the services and interfaces that it provides. All right. Any questions about what we covered on Friday? I know it was a long time ago. It was a weekend. There was a Super Bowl. I know some of you guys were stunned by Tom Brady's continued excellence and amazingness. How many people were rooting for the Pats? Oh, yeah. OK. That includes me. Yeah, all right. How many people were rooting for the Seahawks?  Two years ago, when the Pats played the Giants, I was very upset about that. But I did come to class the next day and I wore Giants jersey and some sort of terrible blinking Giants hat. You can find the videos on YouTube if you want to see that. So anyway, I feel like that was my little, it's been a long time coming, but I feel good final. They won. All right. So let's go back to using PMAP. So PMAP was this nice utility that was designed to allow us to inspect the memory mappings of the process. This is sort of where we left off. It's a little bit rewind of where we left off on Friday. So we were using PMAP to look at Bash. Fairly simple process. We found out that Bash had some executable code here. It had a little bit of space that was reserved for read-only variables. And then there's a little bit of space in this section that was reserved for variables that we can write. We can change them at runtime, but they have values that are stored in the executable. So these were variables that were loaded and initialized from the executable when Bash started running, but were allowed to change them. That's why this is marked to rewrite. Now what are these sections here? Anybody want to guess? Yeah, I think there is some heap in here. So I suspect that this part right here might be the process heap.  Yeah, so the heap is an area for dynamically allocated memory. When a process needs memory at runtime, that it didn't know it needed when it started. If it knew it needed when it started, and it was going to use that memory the entire time, it would have put it up here. It would have placed it up. It's going to be one of those days. OK, it would have put it in one of the other sections. So this is probably the heap. And then what's going on down here? This is a little bit potentially easier to pick out. Yeah. Yeah, so these are shared libraries that are used by Bash. And at least at this point in time, what's the shared library that it's using? The standard C library. Libc probably used and linked by, I don't want to guess a number, but I would say upwards of 95% of executables on most modern Unix-like systems. Link against the C libraries. Just incredibly ubiquitous. It might be closer to 99. Finally, what's going on here? Another little section, 132K. Reading comprehension test? Stack, right? What's on the stack? How do you get a variable onto a stack? So this is actually a great question that's very pertinent for people that are new to C programming. There are three ways to allocate memory in C. Three main ways maybe. There are probably some other funky ways that no one cares about. Three main ways. What are they? Malik? Don't do all of them, just one at a time. Let them answer some questions too. Malik, right? If you allocate memory through Malik, it ends up in here. This is dynamically allocated memory that's managed by Malik. Malik is a library. Malik is probably, in this case, loaded as part of the C library. It's a set of routines for managing that memory. Now, when we get back to memory management in a month or so, we'll find out where the program gets the memory in the first place. But where do you think the program gets the memory from? Who's in charge of multiplexing system resources? The operating system. So, Malik, while Malik is a user library, it relies on the ability of the operating system to manage memory and provide memory to user programs as needed, OK? So that's one way. What's another way you can allocate memory in C? What's that? OK, there's two types of variables, right? There are global and local variables, right? What's different about global and local variables? Scope, what else? So scopus is the technically right answer. And it's also where they reside in memory, right? But from a programmer's perspective, if I change the value of a global variable, where is that value visible? Everywhere. And how long is that value visible? Till I exit, right? So these global variables are the type of stuff that ends up in here, right? Now, not every global variable is initialized by the executable. Some of them are just initialized to have a default value of 0 or essentially nothing, right? Those might end up in this section, right? I'm not exactly sure specifically where those values would end up, right? But when the program is loaded, it can request that the US give it some memory that is just initialized to hold 0s. And that memory might be where some of those global variables live if they don't have a starting value. If I initialize the value to something, then the program has to tell the operating system when it loads up what that value is, and those values end up probably in here, if they're modified, if they're not just constants, OK? The third way, local variables, OK? So if I set the value of a local variable, where is it visible? Only within the context of the code that's executing, right? How long does it hold that variable? How long does it hold that value? Sorry. How long is that value safe to access? Let's think about it that way. Until the function returns, right? The function in which it's allocated, and the scope in which it's allocated, right? Until the function returns, I can access that variable. Once the function returns, that variable is gone, right? Technically, it's still there somewhere. But as a C programmer, you shouldn't try to use it, OK? Those variables end up down here on the stack, OK? So it's a little bit more programming discussion that I like to get into a lecture, but fits in with PMAP, OK? So now we're starting to build our mental picture of what Bash looks like, right? So Bash has a single thread. Remember, we decided there was really no reason for Bash to be multi-threaded. Maybe you guys can write like a super awesome shell Bash multi or something that, I don't know, like draws cats while you're trying to figure out what to type next. Draws cats in ASCII, which would be awesome. All right, so there's some code that Bash is loaded, right? We saw the data. It's got heap and a stack, right? This essentially lines up with, this is the code, this is the data area, this is the stack. Oh, sorry, this is the heap. And then we're ignoring shared libraries because I just got tired of drawing boxes on this line. OK, so now let's look at open files, right? So how many people have ever heard of LSOF? LSOF is, yeah, it's kind of, of all these commands, I feel like PMAP is probably the one that most people don't know about, and LSOF is sometimes useful, right? Why do you use LSOF? Like, what's the use case for LSOF? People that have used it, why did you use this command? Are you just poking around, trying to find stuff out, yeah? Yeah, yeah.  And your computer's like, well, someone's got a file open. So this is where LSOF could be used, OK? So I've asked LSOF to tell me what files Bash has open, OK? I gave it a process ID. And what are these? Dev, PTS, 0. The same file. There's the same file. Well, someone make a guess about what that file actually is based on its name. Yeah? Some sort of device, right? It starts with dev. There's three of them. That's your next big hint. Yeah. SD in, SD error, and SD out. What are those? Standard input, standard output, standard error, right? These are three file handles that the C library opens when you start up a program. And in the case of Bash, what is this device that they're pointing at? It's a console, right? It's a console device that accepts and prints off characters, right? So that's what's waiting for you to type something, right? I have no idea what PTS stands for. It probably stands for something really cool, though. So someone wants to look it up, do you know? What's that? Why are there three of them? I have one open for each file handle, right? So what this means is the shell is printing its output to standard output. It's receiving input, sorry, it's printing its output to the terminal. It's receiving input from the terminal. And it's also writing error messages to the terminal, right? So all of the input and output is going to the same device, in this case, the terminal, right? If I set up a process in a different way, for example, if I use pipes to move data from one process to another, then these file handles don't point to the same things. And we'll go through an example of how to do that later. What's this last file right here? Dot bash rc, yeah. So this is the bash configuration file, right? This is what bash reads at startup in order to determine how you want to print the shell prompt and other stuff like that, right? OK, now I just want to be told, because I want you guys, you and me, to be frank with each other, right? So this is not technically true, right? I doctored this output, and the main reason I did it is because I was embarrassed that there were no other files open than standard in, standard out, and standard error. However, you can imagine that bash would have had this file open if I had caught it right at the right moment during initialization when it needed to have this file. So anyway, that's my mea culpa for the day. I have made this example slightly more interesting through the powers of making things look like they were actually printed by the term, yeah. No, just the last one. No, no, no, I didn't make it all up. Come on, I wouldn't have known how to format the output if I didn't have an example, right? No, I just added the last line there, right? OK. All right, so again, let's just imagine that that's what we call it, OK? So now here's our mental model of bash, right? And this is pretty much done, OK? It has the three resources that we've talked about in the class. It has an abstraction for using the CPU, the thread. It has a set of memory mappings that allows it to use memory. And it has a file that allows it to store data on the disk, OK? Any questions at this point? I'm not going to do this aside. You guys can look at it online. OK. All right, so briefly, let's go. So we just talked about these abstractions. Thread save processor state. Address faces are used to allow processes to use memory. Files abstract away the disk. Any questions about this before we go on? Yeah, you've got to speak up a little bit. Good, because I didn't tell you what processor state is, but we will get back to you, right? So yes, that will be the next unit we will do. We will talk about what state I need to save in order to abstract the process, right? You guys can start imagining it if you want. And as you start working on assignment one, you're actually going to find out a little bit about what that is, the specific example being inside OS 161, all right? And Unix also has this idea of file-like objects, right? So a file-like object is an object that obeys file system semantics, but it's not actually technically a file, right? There are no blocks on disk corresponding to this, right? So can anyone give me an example of a whole file system that Linux slash Unix systems create that's completely fake? There are file systems that live among you that are not actually file systems, right? You think they're file systems. When you look at them, they look like a file system, but inside, they're not actual file systems. They have no data on disk. What's the example of one? What's that? Say that one more time as loud as possible. Peripheral I.O. Yeah, so OK, so that's a good, devices are an example of this, right? But I think I'm an entire file system that's not. Yeah. Not a file system? PROC. How many people have ever poked around in the PROC file system before? How many people have ever noticed the PROC file system before? It's there. Slash PROC. Go poke around in it on your virtual machine. So if you run a mount command, you'll see slash PROC there. Slash PROC is not an actual file system. Slash PROC is used by Unix-like systems to export information about the files that are running on the machine, but there are no contents on disk corresponding to PROC. The operating system just makes up PROC out of thin air. So all the entries in PROC, totally illusionary. They're there for a reason. They're there to allow tools like TOP. So for example, TOP, if you look at the source code for TOP, TOP reads things from the PROC file system, formats them nicely, and then shows you the output. That's how PROC gets information about processes that are running on the system. And a lot of standard Unix utilities do the same thing. So PROC is sort of the interface between the kernel and user space tools for understanding things that are going on the machine. But PROC looks like a file system.  All right, a little aside. OK, so let's go back to Monday. What's the point of abstractions? What are abstractions designed to do? There were a couple of things. I'm going to start using my little magic thing again. So how's deep? Yeah, so that's a good broad goal. One of the ways they do this is hiding undesirable properties. Things that programmers don't want to know about. And once we start talking about the CPU, memory, and disk, we'll get into a lot of these. What else? Another example. Let's go with Josh. Joshua. Josh here. The problem, he could be sitting here completely silent. Pass? All right. Oh, he's looking in his notes, though. Ananda. Be here. You don't know? Something else. Hiding undesirable properties? Alexander. Yeah. OK. So OK, I would argue that these are good mergers of some of our answers. Adding new capabilities is a way of simplifying what you want to do. Because if it didn't have those abilities, you'd have to implement them yourself. And it can be better for the OS to do that. Last but not least, organizing information. So getting all the information about a particular part of the system and making it available in one place. All right. So processes were this very high level of abstraction. They were the one we were going to talk about that doesn't map down to a part of the system. So what's the point of a process? Who can solve the puzzle? Simon. Yeah, you don't know. Oh man, Vanna White is so disappointed right now. She's like, all right, who wants to try Daniel? Yeah, don't know. OK. Anyone want to take a stab at the first part? Yeah. Organize information. Close enough. Close enough. We're not too strict on this version of Wheel of Fortune. And they represent one single thing that what? Process. How do you guys experience a process? Yeah. Yeah, one thing the computer is doing in your definition of doing. Processes contain threads, address space, files, and other things that we won't talk about. These were the things that were a concern. Network sockets, capabilities, permissions, all sorts of other weird stuff. These are the main things we're going to focus on. All right, got it. Thank you. I'm just going to skip through this. This is what we talked about on Friday. What is the contract that the operating system sets up with processes? Again, we'll talk about this in one of the next couple of lectures. The operating system is this special program. It's just a program, but it's been given these special powers. And to some degree, it rules the rest of the system. It makes decisions that affect other processes. Part of doing that is trying to make the system run as fast as possible. But what else does operating system guarantee to processes as part of allowing it to rule, to be the benevolent dictator of the system? You want to answer this question, I think. It protects them from each other. What I do inside of my own process is my own business, but I should not be able to affect the operation of other processes. All right, any other questions before we plunge on? Stunned people into submission. OK, so the first thing we need to do before we talk about the process-related system calls is just what we're going to do for the next couple of lectures. So fork, exec, wait, and exit. Together, these allow me to create processes, allow me to alter what they're doing, set up some very simple ways that different types of processes can communicate with each other, and allow me to get rid of my process when I'm done with it. But as we go forward, we need to be a little bit more precise about how processes relate to files. So here's our old process model. We had threads and address-based files. And here's the small change I'm going to make. Did you see that? Just blur your eyes a little bit. So it turns out that there's actually a layer of indirection between a process and the underlying files. There's an extra level of indirection, which is what we call it when we talk about building computer systems. So file handles. So it turns out there's actually three parts of this. There's the file itself. There's a file handle. And the only piece of process private data is something called the files table. File table contains references to file handles.  So how many people have used open before? Like a raw open? They just call it open in C or C++? What is open return? What's that? I know that's what we call it. Returns of file descriptor. What is that? Have you ever just tried printing it? What do you think? I think it's a tuple, unless you might be using it in some sort of wrapper or something. It's an int. It's an int. It's a number. Remember, computers are good with numbers, bad with names.  So it turns out that number is a number for a reason. It's actually not just a number, it's an index. It's an index into this data structure called the file table. The file table allows the operating system, so when you call read or write, you pass in what you think of as a file descriptor. But all you're passing in to those calls is an int. And the operating system is using that int to figure out what file are you trying to do something to. Has anyone ever got to the point where open fails because they've run out of file descriptors? It's never happened to me either, but it would be kind of cool. Actually, it would probably be a signal that you're doing something really dumb. So the reason that happens is because this array fills up. This array has some number of entries in it. Most processes know we're close to using up all of these entries, but there is a limit. And so at some point, if you call open again, you've got 6,000, 65,000, whatever, two to the 16 or something. The file handle's already open. The kernel will be like, no, you're done. You need to close some of those millions of files you have opened first before I'm going to allow you to open another one. But the reason is that this array fills up, literally. So the file descriptor is an int. And it's an index in the process file table. So that points to a file handle object that's maintained by the kernel. And the file handle object contains a reference to a file object, which is also maintained by the kernel. So the question is, and that's actually used by the file system to figure out what disc blocks or whatever else, if you're talking about something that's not quite a file, I need to work with, OK? Yeah, there we go. Why? Why am I doing this? Yeah, it's like this cat is so angry. This is just to make this difficult, just so I can burn up 20 minutes of lecture today. So why do we have these three levels of indirection? It's a great question. We're going to talk about it today. The reason is because this allows us to share certain file state between processes and their children. And specifically, it allows us to establish certain patterns of communication between certain processes and their children. And so this is a really powerful design principle. If you have a piece of state that you want to have different properties or you want to share differently than other pieces of state, in order to allow that to happen, you need to break that state out of whatever larger object it's part of. So in this case, we have some state that we want to allow certain processes to share. In order to do that, we needed to take these two objects that we had before and take all the information in there and carve it up now into three. And I'll show you exactly how these work. In particular, I wish I had my, where's my thing? So this diagram is correct as I can make it. So the file table and file descriptors, these ints, private to each process. A process cannot modify another process's file table. And processes do not share file descriptors. Again, the descriptors just index into the table. File handles can be shared between processes under certain conditions, which we'll talk about. Specifically, after a process creates a child process, there is potential to share file descriptors. File handles, OK, I need to be more precise. The underlying file objects could potentially be shared among a bunch of different processes, but that's done in a way that the processes aren't aware of. So you're not aware that there might be other file objects that are opened by other processes, but with the file handles, you will be aware, because there's pieces of state that will change. We'll talk about that in a minute. Bug on slide. So I want to add, and you guys will want to keep this list handy. Can a process share a file descriptor with a child process? So in theory, a process can tell the child process file descriptor 4. So I can share it. It's just an int. So if I have some other way of communicating with the child process, like I'm using some other IPC, I could tell it 4. If it tries to use that file descriptor the same way I would, it's not clear that the right thing is going to happen. So for example, if I open foo and my child opens foo, it's possible that the file descriptors we get back are totally different. So if I told the child, hey, write to the file with file descriptor 4 unless we've done something else to make sure that that's the same file, who knows. So yes, in theory you can, but the file descriptor loses meaning once you take it out of a process. Does that make sense? Cool. All right, so what was our first big operating system design principle? You guys can all say it together. I know you've been thinking about it as you fall asleep. Separate from mechanism. Separate policy from mechanism. A separate one is to facilitate control or sharing by adding a level of indirection. And this is something that we're going to see for the first time today, but we'll see again and again as we talk about other operating system abstractions and in other places. So these ideas are referred to as design principles because they come up over and over again even in different subsystems. OK, so I'm going to get back to talking about file handles, but the first thing we have to talk about is where do processes come from? Where do processes come from? It's like the birds and the bees question. The birds and the bees question for operating systems. Where do processes come from? Yeah. What's that? Other processes. I like that. Two processes get together when they decide that they like each other very much. No, well, it's not two processes actually. In this case, Greek men used to fantasize about being able to spontaneously reproduce without involving women. Maybe they designed modern operating systems because processes can create new processes without having to find a compatible process and decide that they want to go into this adventure together. So processes come from other processes, but just one. There's a system call called fork that allows a process to request, and this is now very Greek mythology oriented, that the operating system create not just a new process, but a complete copy of me. I want a complete copy of myself. Right at this exact moment, I just want another me to appear. And actually, I don't know, at least at my age, a lot of you might fantasize about this sort of thing a lot. We usually call it a body double rather than other process, but this is someone who could return things to the store for me, so I don't have to do that, stand in lines. Anyway, so fork. The fork allows a process to say, please make a copy of me, and the process is supposed to be an identical copy of the caller. After fork, this terminology is important, we refer to the process that called fork as the parent, and the process that was created as the child. But keep in mind that they start off, except for one tiny little difference. They start off completely identical, at least with traditional fork semantics. We talked a little bit about how that's changed recently. So now, again, so in recent versions of Unix, there's lots of flavors of fork. But what I'm going to talk to you guys about is sort of the canonical version of fork, the original version of fork. So now you have these tools that allow you a lot more control over what actually gets copied. But the original version of Unix had one version of this that created a complete copy of the child. Now the only place where this becomes a problem is threads. And again, this goes back to early systems that may not have had any support for user level multi-thread. So it's possible that from the perspective of the operating system, there weren't any programs that had more than one threads, and so this wasn't a problem. Now the problem with fork and threads. So here's the problem. If I have a single thread in the process, then there's only one thing that the process is doing at any given point in time. So when the process calls fork, what's the one thing that the process is doing at that point in time? It's calling fork. So if I have a single threaded process, and it calls fork, I know that that one thread is currently calling fork, right? And so I know that nothing else has happened, right? Nothing else is changing the process. There aren't other threads that are running around in the background doing random stuff, right? The whole process has stopped because it's called fork, yeah. Yeah, we'll get to that. Yeah, you're getting to my end of slide, end of lecture slide, right? The problem with multi-threaded fork is that there are all these other threads, right? And those threads may be running, they may be doing stuff, and so the process may be changing as I call fork, right? And that makes the semantics of fork kind of complex because normally when I call fork, what I ask the operating system to do is I say I want a complete copy of myself. But if there's other stuff going on, then the operating system is like, well, when exactly do you want me to do? Like when do you want me to copy you, right? If there's only one thread, I want you to copy me at the exact moment that I called fork, right? That's, I've got everything ready, I've created this perfect clone of myself, and that's when I want that person to start existing, right? If there's other things going on, then this becomes more complicated, right? So the way that modern versions of Unix handle this is they normally only copy state for the thread that called fork, right? Okay, so little, I'm not gonna go through this either. We just talked about this. Okay, so we're only gonna copy one thread, but now let's look at how fork works, right? I copy one thread, the caller, the thread that called fork, okay? I copy the address space, and I need to copy the file table, okay? Now we're gonna see the application this is gonna have, right? So here's my caller process, the process is just called fork, okay? So I'm gonna copy one thread, just assume that thread one is the thread that called fork, thread two and thread three, we're doing other stuff, they don't get copied, right? I copy the address space, including the stack for that thread, right? I don't, those other threads don't exist anymore, so they don't need a stack, and I copy the file table, right? Now, what does it mean in this case to copy the file table? Well, you can think of the file table as containing pointers to these underlying file handle objects, right? Technically, those pointers are stored in the file table array, and the process uses references to access them, right? So when I say I want to do a read to file four, the kernel looks up four in my table, it finds a pointer to a file handle object, and then it keeps following pointers to find out other information about that object. So what does this look like after I copy the file table? Remember, there are pointers in the file table, I'm just gonna copy the pointers. So where are the pointers in the child's file table going to point to right after fork, okay? Say it louder. They're gonna point at the parent's file handles, okay? This is why I took that little piece of state and split it off and put it in its own object because here's when it's shared. It's shared right after fork, okay? So again, fork copies the contents of the file table, those contents are pointers. What it means is that after fork, the parent and the child can share open files. Now it's possible that the child wants nothing to do with the parent's files. The child wants to live its own life, it wants the parent to leave it alone, and in that case the child is free to simply close all the files in its file table and open any new files it wants to, right? If it opens new files, it'll create new file handle objects that are not shared with the parent, okay? This is important to understand. So it's only right after fork that the sharing takes place, yeah. Yeah, yeah, that's not usually how the sharing is done. I'll show you how it's done, right? But yes, right after fork, I would, assuming that the child hasn't modified its file table, neither has the parent, right? At that moment I know that the file descriptors have the same meaning in both processes, right? Okay, so I said there was only one way that the parent and child differed after fork, and that one way is the return code, right? Because otherwise here would be the problem. How would I know whether I was the parent or the child, right? There are times when after fork, I want the parent and child to do different things, right? I want the parent to go off and fork a couple more children, maybe I'm studying, maybe my web server is booting and it's forking a bunch of new processes to handle incoming connections, and I want the child to run off and actually like do stuff, right? It's like real parents, right? You have children, so you can put them to work, right?  And like an idol loop and just hang out, drink my beers, watch football, and let the children handle the web requests, right? That's what we do in my family. We run a web server by hand. So the traditional semantics are if the return code is zero, then you are the child.  How many people have ever used fork? All right, cool. Fork returns two times. That's so weird, right? Like who does that, right? Fork, when you call fork, it returns twice, all right? Once in the parent, once in the child, because assuming that things went according to plan, now there is this other copy of me, right? And again, it's a copy. So it's got all the same code and it's executing at the exactly same place, but it better be. You guys will get a chance to actually implement this for assignment too. And I'm sure you will have times when your child is not an exact copy of the parent or is not executing the exact right spot, right? But anyway, so the point is that I hit this fork, now there are two of me, okay? So you have to think two separate copies of this code executing, okay? And again, the only thing that's different between the parent and the child is the value of this return code, okay? If the return code zero, I'm the child. If the return code is non-zero, and I think positive, because I think negative signals error or something, but anyway, if the return code is non-zero, then I'm the parent. What does fork actually return to the parent? What do we think of fork? What would be a useful thing for fork to return to the parent, yeah? What's that? Yeah, so it turns out fork only reports the status if there's an error. And again, I think it signals that by returning like a negative value, right? But let's say there's not an error, the child gets zero, what would be something useful for the parent to know about the child? Yeah, so that's what it returns to the parent, right? It returns, here's the idea of the child process that I just created. Because the parent may not want to make some notes about that, particularly if it needs to communicate with the child later, right? Okay, we just talked about this. And again, everything contents of memory are identical, the open files are identical, the point where I'm executing is identical, so you can literally think of suddenly there's two copies of the code running together. Oh yeah, absolutely, yeah, yeah. If children couldn't fork after they had a parent then you'd have a very flat process tree, right? But absolutely, right? I mean, so hold on, I think I... Yeah, but remember, not only do the parent and child have the same files open, but there's some state that's stored in the file handle that is now shared. And in particular, that state is the offset into the file, right? So if I move the offset pointer, the child will see those, at least until the child decides to ditch me, go off on its own, you know, live its own life, close those files, handles them real, yeah. So if fork fails, then it only returns once, right? And in the case when fork fails, I think it returns a negative value to indicate failure, right? To do this properly, this code should handle failure, it doesn't, you know, don't write this code, yeah. Yes, absolutely, right? Because remember, there are two, there are, right at this moment, there are now two separate identical processes that are executing the same code, right? But because of how I've set up this if else block, one of them is gonna go down one branch and the other is gonna go down the other. And this is what you see all the time, because again, frequently I want the parent to do something different, right? And I want the child to go off and do something else, right? If fork failed, I would only hit one of these, right? In this case, I would hit the bottom block, but I wouldn't be a parent, I wouldn't have a child. It's very sad, something would have gone wrong, yeah. So if they both added the same? Yeah, chaos, right, without more coordination, right? Yeah. Sorry, no, the exception is that the two, the child and the parent are identical, right? They're executing the exact same point, sorry, the exception is that the only piece of state that's not identical between the two of them is the return value of fork, right? That's the only way you can tell the two apart, right? Yeah, sorry, it's a little unclear. These are great questions, yeah. Yeah, the offsets will be the same, and we're gonna come back to this, I guess it's gonna be Wednesday when we continue talking about fork and pipes, right? We'll talk about how that can be useful, right? In certain cases. Yeah, any more questions? Good questions, okay. Yeah, so we'll come back to this, but someone asked, and so I'll try to get to this just for fun, just to finish up class today. So someone asked, what if I wrote a loop where I just executed fork? What would happen? And I can tell you, so what does this code do? Yeah, this creates an exponentially increasing number of processes, right? This is a program that you can get in trouble for running. If, I mean, don't try it, right? You might be able to, right? But it's, it may be one of the shortest programs you can run on a system, like a production system like Timberlake, and some would be mad, like very mad, right? Because, so this, if you want, like the matrix equivalent of this, this is this, right? This is like, more, and I've actually done this by accident. Not on purpose, I did not write this piece of code, but I've effectively done that through a fat fingering, a portion of a script I was writing, and it's not pretty, right? Especially if you run it as sudo. It's just, you know, like you have a minute or two to say goodbye to your machine, and then you gotta pull the plug, right? Because it just, the whole thing melts down, right? But yeah, this creates bad stuff. So please don't, please don't compile this and run this on Timberlake. If you do, I absolve myself of all responsibility, all right? So on Wednesday we'll talk about pipes and how I can use fork and pipes to set up chains of communicating processes, all right? If you need a partner, come talk to us at 3.30. Good luck getting started with assignment zero and assignment one. You have less than two weeks.


Hello everyone welcome back to another mid-journey tutorial and this one going to show you how to make any type of image three-dimensional like I've got here I've got six examples here as you can see here in order to get the results that I have here and these are not these are first-time results are not re-renders or anything like that all you need to do is type in forward slash imagine happy bulldog comma and then type in what's underneath there that's it six styles in 30 seconds thanks for watching


All right. So welcome to my talk. Today, I'm going to talk about navigating open source business risk. So I'm going to talk about evaluating risk for open source projects. I'll start with a brief overview about why it's so important to actually think about risk. I'll talk about the difference between company-owned open source projects and ones that are owned by foundations, along with some thoughts on neutral governance and how it impacts risk. I'll also share some thoughts about what policies and documents to look for, along with how to evaluate the community risks. Then I'll wrap it all up with a few final thoughts and links to some resources. The presentation is already uploaded on-schedge. So you have the links in the slides to peruse at will. So first, I will start by telling you just a little bit about me. I have been in the technology industry for over 20 years. Working mostly on open source projects from within companies like Intel and Puppet. Now at VMware, I'm responsible for our open source community strategy within the open source program office. I'm also on the steering committee for the Linux Foundations to Do Group where companies collaborate on ways to run successful open source program offices. I'm also a board member of Open UK, which is focused on developing and sustaining leadership in open technology in the UK where I live, and I'm a governing board member and maintainer for the Linux Foundations Chaos Project, which is focused on metrics and open source project health. I have a PhD from the University of Greenwich, where I researched how people collaborate in the Linux kernel. Now, unfortunately, the scenario on the slide is probably a lot more common than people realize. So one of the biggest examples of this was a couple of years ago, when it was discovered that OpenSSL had a security bug in their cryptography library. So that was heart bleed. Now, OpenSSL is a technology that almost every company in the world uses in one way or another. It was during this crisis that most of us learned that OpenSSL received about $2,000 in donations a year, and it was mostly maintained by a single person. So yes, that's right. Software that we all use had almost no resources to actually maintain that software. And there are probably hundreds or thousands of other open source projects in the same or similar situations. Now, this situation with heart bleed was resolved relatively quickly, but we might not be so lucky in other cases. So evaluating risk is important because it can disrupt your business. It's also important to think about risks being on a continuum. So, like with most things in life, there are no sure bets, and no project or technology open source or otherwise is completely without risk. There are only projects with more or less risk across a wide variety of categories, which we'll talk about. And whether you should accept that risk is a business decision. And it should also take into account how you use that project. I wanted to start by talking about why it's important to think about who owns or controls an open source project. Because it's something that many of us probably don't spend as much time thinking about as we should. The project's governance documents can usually help you learn more about the ownership and control of a project. And from a risk perspective, you should be looking for projects with neutral governance, where decisions are made from a variety of different companies. Projects that are controlled by foundations and ones that are owned by an individual company can have very different dynamics. And different risks associated with participating in those projects. So I'll start with a couple of examples of what can happen with projects that don't have neutral governance. Licensing changes are one thing that can increase our business risk. Especially when an open source project is controlled by a single company. So there have been several companies who are fed up with cloud providers selling software as a service offerings based on open source projects. And those companies didn't necessarily give a lot back to the open source projects. So the solution from these companies was to use more restrictive licenses. In the case of MongoDB, they created a new license called the server side public license. It would be used for MongoDB, but also for the security patches for previous open source versions of the software. So this prevents people from continuing to use an older open source version because it's not going to be secure. Now Elastic followed suit recently by moving Elastic Search and Kibana under the SSPL. And it's important to note that the SSPL is not an OSI approved license. So this means for all intents and purposes, MongoDB, Elastic Search and Kibana are no longer open source projects. So situations like this one increase your business risk. License changes require time from lawyers to help us interpret those licenses. And new restrictions on how we can use an open source project can delay our product delivery to our customers.  Governance issues caused by ownership of open source projects can undermine the project's success and lead to disruptions within the project. In some cases, these disruptions make it really difficult to make progress on a project, but they can also result in the project forging and becoming separate projects. So forging a project in particular can be extremely time consuming for everyone involved. And all of this takes precious time away from the development of the project and slows down progress until things sort of shake out and settle down after the fork. And it increases the business risk for companies who are using or contributing to the project. And here are a couple more tangible examples, which we talked about in an earlier presentation. But MySQL was forked into MariaDB when Oracle acquired Sun. And many of the original MySQL core developers, including Mahdi, the creator, just didn't think that Oracle would be a good owner of MySQL and wanted to ensure that the code base would remain open. And in a similar fashion, shortly after that same acquisition, LibreOffice was forked from OpenOffice. And both of these forks created a significant brain drain away from those original projects. Because a lot of the developers moved over and began working on the forks. In the case of LibreOffice, the fork became way more popular than the original project. Now, one way we can avoid situations like the ones I talked about on the last two slides is by supporting projects that are under neutral foundations, like the Linux Foundation, whenever possible. However, it isn't always clear whether a foundation is neutral or not. If the board of directors or other leadership bodies are made up of people who work in a wide range of companies, especially competing companies, that's a good indication that it's a neutral foundation. If the board members are made up primarily of people from a single company or a couple of companies with very close ties, it's probably not a neutral foundation. You can also look at trademarks. If the foundation owns the trademarks for most of the projects, that's likely to be a neutral foundation. If, on the other hand, a single company owns all of the trademarks for all of the projects under that foundation, it's probably not a neutral foundation. And it can help to look at the projects themselves under the foundation, were they originated at a single company, or did they come from a bunch of different companies? Do the projects have leaders from a variety of companies? Do they have a contributor license agreement from a company or from the foundation? And so the more you see references to a single company across the projects, the less likely that foundation is to be neutral. CNCF, Linux foundation, Eclipse, Apache softwares, a foundation are all examples of solid neutral foundations. And one of the reasons that Kubernetes has been so successful is because it was contributed to the Cloud Native Computing Foundation. So putting Kubernetes into a neutral foundation provided a level playing field where people from a whole bunch of different companies could work together as equals to create something that benefits the entire ecosystem. Open source projects that are controlled by a single company are higher risk because they operate at the whims of the company. And there's little recourse for outside contributors when that company decides to go in a direction that doesn't align with the expectations of the other participants within the community. So think back to the examples from earlier where projects moved to non-open source licenses or were forked. Now, for company originated open source projects, consider the reputation of that company as a steward of open source projects. But always keep in mind they can change their strategy at some later date. And I'm not saying that you shouldn't participate in open source projects owned by companies. So VMware, we have a whole bunch of open source projects that we own. But you should think about the risks that you're taking. And in some cases it makes a lot of sense to accept this higher risk. But you should try to at least make sure that you understand the risks you're taking and how those could impact your company. Governance can be found in all open source projects in one form or another. And it helps outline the expectations around roles and responsibilities along with the decision-making processes. But it will vary quite a bit by the size of the project. A project with only a few people will not need elaborate elections to select leaders. But the project should have at least a few basic rules defined, like maintainer for example, and knowing how collaboration occurs and how decisions are made is vital to being able to make contributions that are more likely to be accepted. If the processes for collaboration, leadership and decision-making are not clearly documented as part of the project governance, this can increase the risk of participating or using that project because it introduces a lot of uncertainty into the mix. Now one way to help mitigate this risk is to have some discussions about governance within the community to gauge interest in getting some help with governance. In a lot of communities there can be various types of informal governance that just isn't documented. Quite a few people tend to avoid working on governance. So if it's missing, you might be able to volunteer to help, which is a great way to learn about how the community operates. And it also gives you a gauge for how open they are to actually documenting the governance within the project. Sorry, I lost my water bottle.  At a minimum, there should be some kind of documentation about leadership within the project. There may be committees, working groups, special interest groups, or other groups with opportunities for leadership. If you become an active participant in a project, you will want to understand how your contributors can move into leadership roles. And having employees in leadership roles helps reduce your risk as a company, since these employees aren't a position to understand more about how the project operates and how the project works and be able to mentor other employees and other people into the project. And there are quite a few different options for selecting leaders as a part of governance. And the ideal is to have a process that provides some sort of fair and level playing field that defines how contributors can become leaders. And this should be documented so that all participants can clearly understand the criteria and the process for moving into leadership positions. Bigger projects like Kubernetes have an election process, at least for the top levels of leadership, like a steering committee. But the key is that having a fair and transparent process for selecting leaders, like elections, reduces your risk of participating, since your contributors can participate in the elections. And they can have a say in the governance of the project. Higher risk options would include organizational leadership seats, where a certain number of positions are allocated to specific companies. And those companies get to decide who gets their leadership positions. And there's no easy way for new leaders who don't work for those companies to move into leadership positions. But regardless of how leaders are selected, you want to make sure that there are opportunities for your contributors to move into leadership positions, which will help reduce the risk for projects that you use and contribute to. Now, in addition to the governance documentation, there are quite a few other policies and documents that you can look at as a part of your risk assessment for a project. So security was talked a lot about this morning in the keynotes. People often worry about security for open source projects. Under the premise that if everyone can see the code, they might also be able to find and exploit security vulnerabilities. But the flip side is that there are more people who can view the source code for the purpose of fixing those security issues. Now, within a product team, working internally within a company on a project, you'll have a limited number of people. And an increased chance that your shared backgrounds will lead you to think of things in similar ways. With people from many different companies and backgrounds contributing to an open source project, those innovative ideas will also apply to proactively making the project more secure. And then also, reactively fixing any vulnerabilities that might arise later. However, this certainly obviously does not mean that open source projects are automatically secure. It's not the way it works. One thing I look for when assessing the risk of open source projects is whether they make regular releases, where they quickly patch security vulnerabilities. And you should also look at the project's security policy documents to make sure that they have a solid process for allowing anyone to privately report vulnerabilities and a process for then dealing with those reports quickly and efficiently. Projects that take a proactive approach to addressing security issues and releasing fixes are going to be a lower risk for your company. There are a few documents that even the small ones should have. They need appropriate licensing documentation. They should have a code of conduct that people can easily find with details about how to report incidents along with consequences of violating that code of conduct. The contribution documents should provide enough details about the contribution process so that someone who's brand new to the project can make their very first contribution. And the communication process should also be clearly defined so that people know how and where to communicate within the project. Now, if everyone understands how people within the project communicate with each other, it avoids frustration. So not just for those new users, but also for the experienced ones as well. And again, one way to mitigate these risks is to volunteer to help with some of the documentation. So long-term contributors have probably not looked at their new contributor documents in a very long time. And they may not notice that their documents are incomplete, out of date, incorrect. And someone new to the project can often be a really big help in finding the problems and approving the documentation. And the better all of this is documented, the lower the risk, since your contributors will know what to expect and how to navigate the project when they make contributions. The community can make or break an open-source project and the overall success of a project often depends a lot on the community. Communities usually the first thing I look at when trying to decide if an open-source project is healthy is the community active and engaged in productive discussions about the project? Are they helpful when people have questions or problems? Are they welcoming for new contributors and new users? Do they treat each other with kindness and respect? You'll want to look carefully at how people treat each other on mailing lists and GitHub reviews, Slack, and other communication channels. People with a culture of treating each other with respect and kindness are going to be a lower risk because your employees will want to continue to contribute. On the other hand, projects with toxic cultures can put your employees and other contributors at risk. There could be real health risks, both mental and physical, for your employees. And these toxic environments can impact retention since employees might be so eager to leave the project that they'll look for another employer where they won't have to work in this toxic community. And if the culture is too toxic, this is one of those things that can be very difficult or even impossible to mitigate. So if the community isn't amazing, this is a risk. Now, it doesn't necessarily mean that you shouldn't get involved, but you should approach it with a lot of caution and understand the risks that things could go terribly wrong if it gets even worse within the community and your contributors start disappearing. If you're actively using an open source project, it's likely that you'll find bugs or want to contribute fixes back upstream. So for new projects that you're considering, you'll want to make sure that maintainers and other contributors typically respond in a timely fashion. So seeing large numbers of issues and pull requests on a project is a red flag for me because it can indicate that they either don't have enough contributors to handle the incoming pull requests or even worse, that they don't actually care about or want contributions from other people, which is something you occasionally see. Now, in some cases, you can help solve this problem by making contributions to open source projects part of the job for some of your employees. And so the projects that really don't want contributions from other people, those can be a really high risk because if you're using them, you're going to want to upstream some changes and if you can't get those upstream, you're going to hold them forever and that's going to suck. So we don't always spend enough time thinking about the contributor risk associated with open source projects. For any open source projects we rely on, are there enough contributors that if one of them won the lottery and retired on a beach, could the project continue with minimal disruption? This is a bigger risk for projects that are highly complex or contain technologies that require specialized expertise, like we saw a few years ago with the OpenSSL Heartblade example. You should also look at organizational diversity as a part of the health and risk for open source projects. If all or most of the contributions are from the employees of a single company, what happens when that company has a shift in strategy or gets acquired or runs out of money and goes out of business? Would the project continue if the company pulled all of their employees out of the project? And again, it comes down to risk and whether we're willing to take that risk. Got a few resources that people might find useful. The slides are uploaded on schedule so I'm not going to talk about those but I will leave you with some final thoughts. Most business decisions boil down to an assessment of risk and making trade-offs. And we should all be thinking about project risks in light of how we're using these projects within our business. If we build our products on top of open source technologies, we want it to be as low of a risk as possible. On the other hand, if we're using an open source project and some small part of some non-critical infrastructure that isn't really that important, then we can accept more risk. Now, no project is all good or all bad, all risk, no risk. And no one solution will be right for every single situation. So project risk, like I mentioned before, exists on a continuum. And deciding which risks we're going to accept is the beginning, not the end of the process. Since we should also be thinking about how we can monitor and mitigate those risks over time. We need to think about the risks we might be taking and make informed business decisions about which risks to accept. With that, thank you. And I think we have two minutes for questions but I'm going to go ahead and unplug so the next speaker can prepare. So any questions? Oh yeah, let me off hook that easily, sweet. No, go ahead. I'm not sure that I understand your question. Yeah, I mean, it depends. It depends a lot on the project, right? So we do try to focus on contributions to the project, not necessarily engineering. Sometimes those are other contributions. I was just in a presentation by Omar in the other room and he's basically a product manager and he's been working on Knative and making product and user contributions there which has been really helpful for the project. In other cases, we donate money to foundations. We do a lot of other work. Sometimes, yeah, I don't know how much VMware does of this but projects that I've been on in the past, things like infrastructure and those sorts of resources are really welcome. So it just sort of depends on what the project needs as for what kinds of resources we provide. Like with anything, open source is one of those like, is no one solution. So the next presenter can go ahead and get set up. I'm all off the podium.