So I'll come back everybody in the second half of the hangout. We're gonna talk about the micro master program Now we have a doctor Eva Alfonso and she's the executive director of micro master and supply chain management. So Eva please Thank you And good morning. Good afternoon and good evening global supply trainers. I'm so happy to be here and congratulations You are almost about to finish a C1 X supply chain fundamentals This is great I just want to to share with you some General data about the program the micro master program Let you know that you are part of a huge program with thousands of students very motivated all of them Yeah, just to bring you some share with you some general data Talk a little bit more about the program and more specifically what comes next, which is the the next part of After a C1 X. Yeah, okay. Um, as always free to ask any questions you you might have So regarding the the program so the micro master program started in fall 2015 when president Ray the president of MIT announced the first micro master at MIT They decided to choose the supply chain management was at the first micro master program We we started to Develop create and launch the the five courses that the that Are part of this micro master program? So the the idea behind the program is to democratize the knowledge is to create a program Open for everyone for anyone anywhere just with a computer a laptop or a computer and internet connectivity You can access to this massive open online courses open enrollment As you know so you can enroll in the course and the materials are for free for everyone If you want to pursue for a certificate, then you need to to be a verified student That means that you need to pay a fee one hundred and fifty dollars per course Also verify your identity and in this sense you are going to be a verified a student and you come pursue for this Certificate Important part of you know verification the idea application. I mean, which is summer students forget to you know This is something that you need to fix as soon as possible the verification process include two steps First is that you need to pay the fee that means that the fee to for the certificate The second part is to verify your ID and this is a very relevant You need to to take your picture your your ID government a car picture to and the verification is a must It's something that you need to be is required if you do not need this requirement You are not able to to to have the certificate in in se1x So please fix this as soon as possible if this is the case So then a fall 2015 president raised rape announced the the micro master programs apply to in management well, this is a a new program in the sense that is a Graduate level Courses that means that the contents that we are teaching in you know sex courses are a Same content that we are teaching here on campus. So these are gradually to level a contents After completing the five courses Student can apply for a master degree at MIT. So this is a new way to to have To have a student and to admit a student at MIT in a master degree program So this part is very is a new way to to to to offer this Master level education to to to people around the world. So some general data about the program So far since we started the first course was developed by Chris Kapliz in 2014 and was this course was a se1x supply chain fundamentals. This was our first course in the program in 2014 and since this moment to now more than 170,000 students Have been enrolled in our courses in our different sex courses. So from from this number 11,000 are verified learners learners that We mentioned they pay and they are ID verify the student and they are from more than 196 countries Almost so almost all the countries, you know, it's almost 200 here And so far today, we we issue a more than 14,000 certificates in the in the program different sex courses, okay, so This is about the General data about the program. Let's see now where our students are from. So maybe they are from the 20% of our students are from the United States 10% are from India and this number is getting is is raising a lot in the latest The latest course that we just opened the number of Indian student is almost 20% It's touching the 20% we also have a lot of a student from Brazil from Mexico from Germany from Spain from yeah Spaniards Okay, so yeah, so this is where our students are from. Let's have a look now to them To the program. So the micro master program as I mentioned before includes five massive open online courses You guys I guess that you already complete a Supply chain analytics. You are almost about to finish supply chain fundamentals and C1x The next course is supply chain design supply chain design We are going to open a week zero This Wednesday on April the fifth and week one the first week of contents is going to start on April the 12th So if this course doesn't start right after completing a C1x So we and then after supply chain design We we will offer supply chain dynamics in June 2017 and then in fall 2017 We will offer again supply chain technology and systems So with this you will have the opportunity to complete the five courses that are part of the micro master program Once the student pass as a very fight the five courses then they can see it in the proctor Final exam. This is going to be a comprehensive final exam And the idea is just to assess your your knowledge in the five courses and to assess the that your Ability to apply all of the concept that you have learned in the micro master program at the end of the program Then once you once you pass this comprehensive final exam You will be able to earn the micro master credential in supply chain management This is a an standalone certificate the certificate Allow you to go to the industry to apply for a job or you can also apply for a master degree program You can do this at the 19. We are offering what we call the master Master degree program is the master the blended master a supply chain management So you can apply to this blended blended master here at MIT But also in different universities around the world Saragossa is offering this and all the universities And if they apply if they get that certificate and if they apply and if they get approved They're gonna sit together with the traditional MIT students Yes, definitely. There are two things that I want to have. If they go that mission then they are going to be part of This blended program and doing this this semester that they are going to spend on campus They are going to spend five months on campus. They are going to share with the regular residential students Courses classes and they are going to be part of the It's a great opportunity definitely The the question is as always It's limited we can only offer to 40 students per year per Program, but yes, it is a great great opportunity This is a very good point I'm at because since they they can apply to this program if they are Admitted in the program then we are going to convoy rate The the courses the SCX courses as MIT credits That's why it's also very important the comprehensive final exam and we need to also to assess the knowledge Because at the end these five Courses are going to be equivalent to 42 units of credits at MIT. So this is also Important point here. Thank you. Okay, so let's Go to the next slide So we we we are now Almost almost about to have our first micro master pipeline Coords these are the students that already complete and pass as a very fine C0x a C1 a C2 a C3 and they are now almost about to Complete a C4x next week is going to be the final exam and we have 1200 students that are Potential candidates to be micro masters student and to earn the micro master certificate Where are these students from? They are 30 percent are from the United States a 5% the second country is Spain go with Spaniards from 5.6 percent Is the second country and then we have people from India from Brazil and Germany from Canada from? Yes from more than one hundred Counties also UK. Yeah, it's another important Country represented some people from Australia 1.3% of our students are from Australia too. So yeah, so this is the first a Core the first micro master pipeline This is student. They are going to have the comprehensive final exam May 2017 by the end of May they will have this comprehensive final exam And after that they will earn the certificate they can use for for apply for a job Or they can use to apply for the master degree at MIT or a other universities that are also in this blended program Okay, so this is about the current micro master pipeline let's come back to To to your curriculum you are currently as we we mentioned Almost about to complete se1x. So what next next is se2x What are we going to do? What are you going to learn in supply chain design supply chain design? It's a course that are going to take care about the flow of material We are going to to teach how to To solve network design problems and we are also going to Analyze and to study the flow of information and also the a finance flow the So in se2x you are going to have a the first block about a Network Problems then we are going to go to a production planning then we will move to a procurement And finally we will cover finance in supply chain. So this is mainly the The contents that you are going to review and learn in supply chain design After this course and we will offer supply chain dynamics Supply chain dynamics. Let's say it's going to be a little bit more qualitative course We will review here Supply chain dynamics We will go through supply chain strategy and also through global supply chain So we are going to to be out with the complexity of having let's say suppliers all over the world analyze the main challenges that a Most of the manufacturers retailers have when they need to be out with a global supply chain At the end of the of the program And you will have supply chain technology and system in this course. We focus mainly in In data management, we are start with the data analytics some How they teach you how to to design a relation and database management Also, we will move to supply chain systems. We will review the ERP system enterprise resource planning system We will also have a look to those supplier relationship management system customer relationship management system and also to more a Executive system like the transportation management system or warehousing management system So it's all about how to manage the information flows in a supply chain How the information technology is helping companies and organizations to manage this flow Then the the final comprehensive exam so these five courses we almost cover Know all the things in all the you know key concepts and key builds in the supply chain management So as I see we cover everything. So that's great Yeah, let's say that the the program is intended to cover the basics In supply chain management We are starting with the analytics tools that analytic tools that they They need for the all of the courses and then we move and we start to but it's also very applied all of the concept that we we Present in this program we try to apply to to real problems or to Realistic problems in industry. So let's say that we are starting with the basic tools Analytics the supply chain analytics and then we we start to go through inventory management and we go to network design problems or to Global supply chain Problems and try to apply the different tools in different contexts and problems in supply chain Yeah Okay, so in terms of a C2s as I mentioned a C2s is going to start Next Wednesday in one week so far we have 16,000 learners enrolled and I expect to increase this number During this the next week since you guys are now finishing a C1x We are now just Starting to promote the course and just the course is going to open in one week So so far we have 16 learn the 16,000 learners from 179 countries Week one that is the first week of contents will start on April the 12th So if the a C2x is the in terms of the structure of the course is going to be very similar to C1x and a C0x so far now we have eight weeks of content We are going to have you are going to have a meter exam plus a final exam one week time exam both One week off before the meeting on the final just to give you time to complete all of the great assignment before the exams and also to have time to prepare for the for the For a C1x week 11 is the so-called off-peak, but you have some materials in which 11 no great assignment, but there are some videos that that's assume it to be Off-peak for a C1x The week off the most important part for the week off is you do not have you are not going to have great Assignment in the week off. We always try to include some supplemental material Extra material something that can't help you maybe to have to wrap up the concept to fix some concepts that we already Thought in the course, but These weeks we are not going to include any great assignment because we really want to give you time guys to To complete the previous late assignment and also to prepare for the in this case for the fight final exam Yeah, forget next week is the final. Yes April defeat is going to open April defeat. It's going to close a Okay, can we move to the next slide please this one and the next one Excellent. So then as I mentioned in a C2x supply chain design We are going to cover all of the aspects involved in the design of a supply chain from the physical flow information flow and Monetary flow and finally we are going to to wrap up with the organization design We are going to use all of the basic tools Probability statistic that you you have learned in SC 0x Also, some of the tools that you have learned in SC 1x and then we are going to apply this concept in order to design Supply chain network Yeah, you have to prepare you for a C3 and a C4x. Let's have Yeah, so after each course as you know, you if you are a verified the student you can earn a Verified certificate This is per course so so per course so in each course you will earn the Certificate per course and at the end of the program once you pass the five courses as a verified the student and the Comprehensive final exam then you will earn the micro master credential the certificate in supply chain management Micro master credential in supply chain management As I mentioned a this is something that a Can be used to apply for a master degree a Program here at MIT Also in Saragossa and other universities Let's have a look now to the profile of the of our students So as you know, we have thousands of a student and is very We have very different the student from very different cultures and different also profiles So we have a student with that they are currently working in supply chain management. They they are seniors They have more than 15 years of experience They really won't just to to train themselves. They really want to be update with their Tools and the latest software some and try to to learn more about supply chain management And they are doing that and they are really really You can't see them in them in the forums and they are providing a very good insight and comments About the course the concept they experience So they are bringing let's say their experience to our courses We also have this profile of people that they have some a Two to five years of experience in supply chain management. They they just Recently entering the supply chain management field and they really want to to improve their career So we have this a kind of a student that are also trying to do these micro master credential in order to promote In the in their current jobs We also have those a student that that are a student. They are a student that already Got a bachelor degree They are pushing for a master degree or they are pushing for a for a PhD degree sometimes And we really want to know and learn more about supply chain management. So We also have a this profile of a student and some companies are you know, you know recognizing this micro master program, so it's going to be A good program. So I think if you have this certificate in your CV resume, so it's going to be helpful Yeah, definitely is is at the end the program covers the the basic the Foundations of the supply chain management So it's a way to to demonstrate that you have the ability and you have the knowledge in these Basic concepts in supply chain management. Okay, I'm just to wrap up some testimonials that I know that you all love this. We have a sneak from India He was very thankful because he thanks to this program. He Finally he got a job in supply chain management We also have Maria from Spain Maria was a Bachelor student in the technical University of Madrid She's now a master degree student in Denmark and she she really wanted to learn more about supply chain management She wanted to apply to to the master degree at MIT So these are just some some examples and this is the team. This is a team effort. This program cannot happen We do not have this great team with our teaching assistant with our postdocs. I'm at a did a great job coordinating this course Arthur with he's our community manager This is the one that really really is the king of this program is Filming all almost all of the videos. So this is great and hopefully definitely is a team effort So this is just a picture of on the team that are behind with many many hours of work doing this for for you guys That's all from my side. Thank you so much. I'm so happy to be here with you today Let me know if you have any questions. Thank you so much You are so we actually running out of time. So and you cover most of the things and I think Yeah, we are all set. So and I know that Arthur is replying people so Thank you so much. Thank you so much. It was the last hangout event for sc1x See you in sc2. I'm best of luck in the final exam and see you in sc2x. Thank you. Thank you


All right, I'm going to start. My name is Michael Johnson. I work at RPATH. I'm going to talk about some of the open source technology that we've been creating at RPATH specifically for packaging. And I've heard a lot of pronunciations. We call it canary. I want to talk about how their packaging process is simply powerful. We have a simple process with powerful features. The way we make that work is that whenever canary does the wrong thing by default, we'd make it easy to override and make it do the right thing. I'm going to talk about how we fight bit rot in packaging by enabling just enough packaging. I'm going to talk about what I like to call dependency heaven, just enough operating system. So I'm only going to talk about packaging here. I'm not going to talk about the process of using canary to manage your system, to install packages on your system. Only the building packages with canary. I'll only talk about system management as it relates to the process of building packages. I'm not going to talk about canary repository management. I'll just mention that canary stores everything in a web-accessible repository. And I'm not going to talk about building system images with our builder. Let me go back to my initial slide for a moment and mention that this URL on the bottom is currently live. And if you have your laptop, you can follow that. Many of the items on these slides are actually links, so you can follow them to more information. So the first question is, why canary? There are already several packaging systems in the world. And people were a little bit annoyed that those were not unified. So we'd have to have a pretty good reason for creating yet another packaging system. The answer is multi-fold. But one of our key ideas was that we would enable system management modes that are inspired by concepts in source code control. Particularly, the new lessons we've been learning as distributed source code control has become common. We also have extensive experience in what I like to call legacy packaging systems, like RPM and depackage and so forth. What I mean by that are package systems where the main definition of a package is an archive file as opposed to our concept of a package, which is something that lives in a repository and there's a lot more internal structure to it. So here are some of the things about legacy packaging that we found are good and bad.  One of the things that we really liked, particularly those of us who started this who had done a lot of RPM work, was the habit of using pristine upstream sources plus patches when you're building a package. So that when you go to a new upstream version, you don't have to recreate an archive. Another really important thing that happened relatively early on in today's modern legacy packaging was automatically discovering some dependencies. The typical example of this is shared library dependencies. But we also, based on these, this decade of experience or so had some very strong ideas about what was wrong in legacy packaging. In particular, we found that the control files, whether it's a spec file in RPM or anything else of that type, tended to be very verbose and have contents that were copied from spec file to spec file. And that introduced bit rot in a variety of ways that I'll talk about more. It's very much a two-manual process. We just had to do a lot of things manually that could be done automatically. And I would say a classic example of this would be percent files in the RPM spec file. It was also too complicated. There were just too many things you had to know how to do to get started. You had to read a book practically. There were two interestingly linked problems. The dependencies were insufficiently complete. Just because the dependencies were satisfied didn't mean that a package was really likely to work. And the other interesting thing was that dependencies, even though they weren't complete enough, were too broad. They were insufficiently specific. And so you end up with what gets called dependency help, where you drag in lots of packages that are unrelated to what you're trying to do in an attempt to get a working system. The last thing I'll mention is that scripts are often buggy. That's the post install, pre install, uninstall scripts that get run while you're installing or uninstalling packages. And we looked at reasons why they were buggy. And I found two real big reasons why they were buggy. One was that people would copy a piece of script from one place to another because they didn't need to write everything by hand to start with. And they would copy things they didn't understand. And so either a piece of script would work in its original context but not work correctly in the context into which it was copied. Or it might be a bug in the original that someone didn't understand when they copied it. Or when they're copying it, they might make a mistake in the copying. So there are really three kinds of errors that are introduced by having each of these scripts be specific to all the individual packages. So we went through and investigated a bunch of build systems when we were starting working at Canary. And we came up with some goals for the packaging process based on our investigation and our experience. One of the things that we noticed that was bad that I didn't even list was that information was commonly duplicated. Typical example of this is in an RPM spec file you have two mentions of every patch. You list it as a source and then you have where you apply it. And very often people who could apply in a patch but still reference it, so it's still part of the package but not applied. It made it unclear when patches were applied and not applied. So we want to provide only once and only necessary information. You shouldn't have to copy a lot of boilerplate to make things work. We wanted to do the best thing by default. One of the problems, RPM has something that they call policy, RPM policy. But it can't be very powerful because it's very hard to override what it does. So it can only do a little bit. We wanted to extend the concept of policy to be able to fix lots of things, find lots of errors. And if we make it very powerful, it might not always do quite what you want. It will do the right thing in the 80% case or the 90% case. But you need to be able to override it. So we needed to make it very, whatever decisions we were making at any level of packaging, we want to do a very powerful, sane, consistent thing by default so the package doesn't normally have to specify what to do, but make it very easy to override when something goes wrong. We wanted to avoid copying errors. And when I say copying errors, I've just mentioned three kinds of errors you can have in copying. We wanted to avoid all of them. We also had a very important goal that came from looking at distributed source code control. And that was to branch without forking. To do a branch that tracks what's being done upstream with some change applied. And we have this concept in multiple places in Canary. Finally, we wanted to enable reproducible builds. So our source packages are stored in the repository with everything you need to build them. Our control files specify clearly and completely what to do. And then, because I say clearly and completely, if there are no bugs, it's not software, right? So sometimes something wasn't reproducible that should have been, we record what was really done, and then you can go look back and figure out what changed. So we called our control files recipes. We wanted to have a different name, so it was clear what we were talking about. Eric Tran, one of the other co-inventors of Canary, is a gourmet cook. So we called our control files recipes and the process of building we call cooking. And again, we want to do the right thing 90% of the time and make it easy to override for the 10% case where we can't do quite the right thing by default. These recipes are implemented in Python, but that's not really very important because we have restricted what you do in a recipe to turn it into something of a domain-specific language. What you're really implementing is a subclass of a set of a class that brings in other classes that are pulling in thousands of lines of Python code, but what you're implementing is basically a class that sets up lists of things to do, and it's not actually doing the processing from code, so it's more declarative than you'd expect from saying they're written in Python. So we have infrastructure that we've created to intentionally inhibit complex code. When you're reading a recipe, you don't see a lot of conditionals.  And so instead, our conditionals are expressed in terms of configuration items, and those configuration items are stored as part of the packaging, and we call that a flavor. So if you build your package once for x86 and once for x8664, your conditional is based on am I building for x86 or x8664? You could also say I'm building for having SSL enabled in this package or not enabled in this package, and you could build both of those flavors and store them both in the repository. And you can do arbitrary combinations of these, but the fact that there's a conditional is recorded in the way it's stored, which makes it possible to reproduce what you built the last time and know how it was built and why. The stages of processing these recipes is a little bit different from other packaging systems. Yeah, this is a little bit familiar. You start with preparing sources. Pretty much everyone has a stage in which they prepare the sources. So if you've used RPM, RPM-BP, RPM-Build-BP, it's essentially equivalent. But then we do not at all separate the build and the install phase. So if you have a source file that doesn't need to be processed or modified in any way, say a config file, in the preparation stage, you can install it directly into the tester, the proxy for the system where it will be installed later, and you never have to touch it again. So even the preparing sources phase can already start to do the install phase. But other than that, the build side, the make and make install will live in the same part of the process. And then the last stage is checking the results with policy. And I'm making sure that, I say checking, it's checking and possibly fixing the results of the build. So here's a little bit more detail about how to prepare, how Kanari prepares the sources. You can provide a partial URL and it will guess the name of the archive. So all these examples here are directly pulled out of existing real recipes. In our SQLite recipe, it turns out that SQLite just lives at HTTP colon slash slash SQLite dot org slash SQLite dash version dot tar dot bz2 or tar dot gz. And all we have to do is give the base name of the URL, tell it that the name is SQLite and the version is whichever version we're building and it knows how to go fetch it. Similarly, we have a mirror system. If you've got something that's stored in the whole source forage mirror system, we will just go through and iterate over a whole bunch of source forage mirrors looking for all these different archives until we get the first good match. There's a patch, you can reference things by URL or you can check them directly in. So we have an example here of a patch that solves a security issue. You check that patch into the source component and reference it directly. So that ad archive can add all sorts of archives and automatically know what to do with it. Not just tar and CPIO, it can bring in RPMs and optionally if you're bringing in a binary RPM it can even honor user names and modes and stuff directly out of the RPM. We can even unpack ISO images directly. We can also add patches which are automatically applied. You don't have to say first add a patch and then apply it, it's all one thing. You can add individual source files and you can even pull directly from source control systems. So we have a place where we build snapshots of the latest canary out of our mercurial source code control system. We just say add mercurial snapshot from this URL. If we wanted to we could say tag is such and such a version and build from a tag instead of from the tip. But all of these things including when you're building from a source code control system, when you've prepared the sources and you're committing your source code to the repository, it looks all this up and stores it all in the repository. So even if SQLite someday deletes a version of an archive, you'll still be able to rebuild that specific version of SQLite because all the sources are stored in the repository. However, the things that are referenced by URLs when you check out a source package don't automatically get brought down to your machines. You only get the files that you've checked in directly like the CVE patch, the example here. So that means that a checkout of a recipe is very fast. Then it doesn't matter. You can mix and match the commands that add archives and the commands that do builds. The first it does all of the commands in order that work with source files, archives, source files, patches, so on. And then it does all the things that are build actions like configure and make and make install. And we provide sane automatic defaults that's the, as appropriate for the command, arguments and environment, so that builds are consistent between packages. All the packages will by default have the same C flags and CXX flags and so on, LD flags, so on and so forth. So configure that this is a method you can call that will invoke configure with a consistent set of default command line arguments. It'll set prefix, it will set datadir and libdir and all of the standard configure command line arguments so that all of your packages are configured the same way. And if you need to, you can override them. And then when you call make, it will set environment variables like C flags. And when you call make install, it will have all those same environment variables, but in addition it will set destor. And to the proxy root so that when you're doing your make install, all the files will be installed in the right place. One of the things you don't see here is anything like a file list. Whatever gets installed in that proxy root is part of the package. Anything that's not there is not part of the package. So we've encapsulated most of the common build and install commands. And if you were here for the last talk, one of those is CMake. We add them as we get reasons to add new commands. So it's not that hard for us to add a new command. It's a few lines of code. But then that makes sure that builds with that tool continue to be consistent. The question is why can't you just say r.build and it will do configure make and make install? We'll get there. I'm trying to give... So let me step back for just a moment and mention that I'm trying to give here the concepts that you need to understand Kanari. And if I talk fast, I'll actually be able to show you some slides from another presentation that has a lot more specific details. But I will get to that specific item. After all the build install phase is done, then we go through policy. And we have over 100 basically automatic operations that get run across every single package. And there's... It replaces a lot of manual work that's done in spec files. An example of this would be... There are many distributions which by default have a policy of removing the libtool.la files because they're not needed for most things. They're just extra files on the file system. And so they remove them. That can be done as a matter of policy. A lot of recipes go in. Make install has happened to have installed twiddle files, backup files from Emacs or something. And so they have to work around that by removed, you know, find Pypex, argsrm, or something like that. We just have a policy which knows a whole bunch of file types that should normally not be on the system. So examples of these policies, other examples, generally transparent multi-architecture support. We've got multiple policies which investigate your build and we'll notice things. If you're building an x8664 and you have some things installed in the lib and some into lib64, it will try to move everything from lib into lib64. And if that doesn't work because there's a file conflict, then it will create an error. Otherwise, it warns you. Another example of a very trivial kind of policy which has noticed several bugs, non-binaries and binders. We just have this list of common directories that should hold binaries. Bin, sbin, userbin, user sbin, userlibexec. And if you find a file in there without some execute bit set, that's probably a bug. And so we raise an error. Now, if you know that you have a reason that you need to have a file in there that is not executable, you just say, the error comes out saying non-binaries and binders found this non-executable file. You can say non-binaries and binders exception for this file or for these files. So, as I said, they're easily overridden with information that Canary provides at build time. So, not only are they easy to override, they're easy to enhance. So I'll get a little bit ahead of myself and say that Canary has a very interesting dependency handling. One of the cases that sometimes shows up when you have a launcher script for an application that sets a library path, well, you can't resolve the dependencies without knowing what that library path is. So you can tell Canary, build up the libraries based on this LD library path existing. That's an additional... Computing dependencies is a policy, and that's additional information that you provided the policy to help it do its job right. It's not usually needed, but for things like Firefox it is. It's also easily augmented. I say there's over 100 operations. That's what we distribute. But anyone else who wants to build an operating system on top of Canary can implement their own policies and make those part of the system on which you're building, and then those will also apply to your packages. So, here's an example of what our recipe looks like. And this is a made-up example I just typed out to show the structure, right? Class, my application. OK, you can see this is Python a little bit. It is an auto-package recipe. This means this is a package that uses the standard configure make-make-install process. The name is my application. Version is 1.0, and it requires a development library and a runtime from a few random packages in order to build. In order to unpack this, I need to go... I'm sorry, I'm missing a trailing slash on my example there, but you need to go to this URL, find my application-1.0.tar.dz2 and unpack it, and then because it's an auto-package recipe, the default is that it runs configure make-and-make-install. Now, if you need to pass extra configure arguments, you say that the configure stage is to call configure with these particular arguments. Most of the time you don't need that. So, this is kind of an idealized recipe, right? That I just typed up to show how things look in the general sense. You probably want to see a real recipe just cut and pasted from a real source component. That's incredibly more complicated. It has three build-requires instead of two, but that is actually the exact content of version 222 of the Xyle recipe that I pulled out of the repository, and many of our recipes are that simple. Some of them are even more simple. So, I see that this is an auto-package recipe. You're not left limited to the superclasses that we've defined for Canary. You can implement your own, and so an example of this is that there is a GNOME package recipe. Well, GNOME package recipe knows the GNOME standards for where archives are kept, and you say this is a GNOME package recipe, this is its name, this is its version, and the GNOME package recipe lists common build requirements for GNOME packages, and so many GNOME packages don't need anything beyond that common set. You may not even need to list build requirements. Just name and version, and that's the entire recipe. Three lines plus any copyright statement you want to put on a three-line file. Now I want to move on to some of the characteristics of the process, and I don't know that this gets into a little bit of how you install... how Canary installs packages on a system, but only in as much as it influences the process of packaging. So, it's transparent. It's easy to see what's happening. It's repeatable. You can go back and rebuild something you built before and be confident that you're going to get the same thing out of it. We automatically subdivide the packages into components. Now, if we go back to the recipe, you'll notice libtermcap develop and techinfo runtime. We'll see a little bit more about that. We have very rich file-level dependencies. Everything in Canary is done on the basis of individual files. That's the core object. And we have a robust system script design. And I say system script, it's the thing that would replace post-install, pre-install, uninstall scripts and things like that. Triggers. So, how do we achieve transparent and repeatable builds? First of all, as I mentioned, all the sources that are needed to build a package are stored in the Canary repository. If that doesn't happen, it's a bug in Canary. I can give you an example of that. We have the ability to authenticate via a GPG key. We don't currently store the actual key that we've downloaded from the key servers. That's a bug we're going to fix in the next few weeks. We just realized it when a key server went down and we had trouble building something. Build requirements are automatically discovered. So, you remember that list of build requirements? I built without that list on a system, and Canary told me that I needed to add those items to the list. Also, when I say packages that satisfy build requirements are recorded, what I mean is when you're building the package, it actually looks at the system database and sees exactly which versions of all the packages needed that satisfy the build requirements. And it's not just the build requirements that you have explicitly listed in the recipe. It's all the build requirements that's inherited. So, for example, the auto package recipe is going to have all the build requirements needed to run, you know, configure, make, make, install, you know, the C compiler and make and shell and awk and set and grep and tools like that. Then, the entire log of the process of doing the build, including adding the sources, adding the patches, doing all the build actions, exactly what shell command was called for each of the build actions, all the output from policy is stored in a build blog, and then that build blog at the very end of the process is put into the package. And so the build logs display all the actions that are taken during the build. We also store debugging information on the packages. So, if you're familiar with debug info packages, we have debug info components. So, speaking of components, files are automatically assigned to components. You don't have to decide whether to create food develop or not. You have a package which has one binary, one library, one header file, and you think, oh, it's too much to split it up, so I'm just going to create the food package. The problem with that is that if you're building against the library, you pull in the runtime, you pull in all the libraries that runtime depends on and so on and so forth, that's what creates the dependency-hell problem of cascading dependencies. So, the problem with having all of those lots of little components, if you had the concept of a package being one file on an FTP or HTTP server would be unmanageable. You'd have 10,000 files that you'd be downloading via FTP or HTTP or something. The fact that we have this repository model that's more like a source code control repository means that it's not a problem. So, the way we assign files to packages is regular expressions and file modes. So, you can say, this goes into this component only if it's executable or if it's not executable. And it's easy to override. You can say, no, I know that even though this file is not under user share, it still belongs in the data component as an example. So, I say that we have six or eight components per package and we have, so we have about 800 packages in a core distribution that turns into close to 8,000 components actually. That sounds like a nightmare for the user because they would see this huge amount of information about updates. In reality, it's not because we have something called a group that I'll talk about later.  I'm updating from state A to state B. And the groups that I'll talk about later turn that from what would be an update, a nightmare to understand your update to being very simple to understand what's happening. Canary's dependencies are semantically very rich. So, if you're used to a shared library dependency, you can use the library to implement the system 5.0.2. Canary has a very different view. We say it's l32 or l64, lib4.so.2 that implements the system 5.0. And the x86 or x8664 or ppc or what have you instruction set and on the provided side declare all the symbol versions that are included in that library. On the required side declare all the symbol versions that are included in that library. Used by the linkage to that library. And we can then match those up. The dependencies are per file. So, for every single file, we record that file's provides and requires all its dependency information. And then when we're creating packages of files, we roll that information up into the package. And the fact that we create these components avoids the dependency creep. The main handlers are our answer to system scripts. When you install a package, or you're making some packaging change, and you need to do something on the system. In order to avoid having to copy information from one script to another, we have just one script for each kind of thing that needs to happen, whether that's installing an info file or installing a kernel. Any of these kinds of things is one script. So, each file has zero or more tags. A file is an info file. A file is a kernel or kernel module. A file is a...you name it. And then you have one script on the system, which runs and knows how to handle installation and uninstallation. And this means you never copy yours. Now, could you have a bug in that script? Yes. In practice, there haven't been a whole lot. But because you're able to focus your attention on making...doing a good job of one script, the good news is if you fix a bug in the script, you fix it for all packages, even old versions of other packages. So, for example, let's say we founded a bug in the script that installs an info file. Maybe there's a missing dependency or something. When you install the new version of techinfo, which includes the script across those info files, it can go fix up all the mistakes it made before, even for packages that were created before that fix was created. You don't have to propagate the fix across 50 or 80 or 100 packages that contain info files. So this is robust. You don't just transcribe errors between control files because they never show up in the control files. In the first place, there's no transcription to happen. It only runs when there's a relevant change. So if you're updating from version one to version two of your package and the info file hasn't actually changed between those two versions, the fact that Canary does relative update, something I haven't mentioned yet, means that that file is just not included in the update at all. And because that file is not included in the update at all, that script never runs. So there's no chance that it's going to break anything by running when it doesn't need to run at all. It also, because we've made the concepts of installing and uninstalling a system-wide thing with a system script, it means that we have robust rollbacks. And an example of how robust our rollbacks are, Matt Wilson, another one of the inventors of Canary was on his system and typed in the wrong window a command that started erasing his entire system. And we noticed this when on IRC, he said, oh, no, and then we saw MSW has quit. And he caught it with control C halfway through erasing his entire system. Canary rolled back one, and about one minute later, his system was back and his back on IRC. And I can give more examples of that if you're interested, but not right now. Finally, I want to go through the process of building at a little bit higher level, the process you go through when you're building. First of all, we have a tool called Armake. It's part of our Canary suite and show you how package building works in Armake. I want to talk about shadows, which is our concept of branching without forking. I want to talk a little bit about groups, which is how we define consistent sets of packages. I want to talk about some of the capabilities we have for inspecting what's in packages that you've built and also the process of testing. First of all, the Armake tool. The Armake tool looks at the build requirements that you have listed in your recipe, plus all the build requirements that you've inherited from your superclass recipes, and the full dependency closure of all those explicitly listed dependencies and creates a clean change of environment. But it only has the things that are listed as required or needed to have a dependency closed set of packages installed. Then it builds it and commits it to a local Canary repository. It's actually running the Canary repository code on the system, and it commits it there. From there, you can install it on your system and test it. You can inspect it with all the tools that I'll mention for package inspection. And then when you're satisfied that the build is good, you can commit it to a permanent repository from the temporary working space on your system. You can also build from multiple architectures from one console. So if you have an x8664 system, you say Armake build foo for x86 and x8664. It'll start up both builds. It'll do them serially if you've told it to do one at once. It'll do them in parallel if you've told it to do more than one at once. And build them all. And then you can commit them together as one transaction. So the repository sees one transaction that is both x86 and x8664 builds. And you can do that for any kind of configuration changes you're trying to make. Building the SSL and not SSL versions for x86 and x8664, that would be cross product as four. You'd be committing four different configurations or flavors of that one version. Shadows are how we branch without forking. And they track changes relative to an upstream version. So a typical use is to add a patch or a configuration file or to build separate binaries against different base OS versions. Examples of this. We have customers who want to use a library that we provide as part of our operating system, but they need to have a configuration or maybe say PHP. They want to change PHP.ini to allow more memory for their particular systems that they're building. And they could create a shadow of PHP and modify that one file. We have a facility, a special kind of shadow that's called a derived package where you don't even have to rebuild it. You just say, install the upstream version, make changes to it, and repackage it. Well, it's useful for building separate binaries for different architectures or different base OS versions. The same recipe can build differently in different contexts. R-path Linux or foresight. Now that it was just announced someone ported Canary to open Solaris, maybe you'd take the same auto package recipe because you can look at Xile at recipe. You see, there's nothing in there specific to R-path Linux or anything. They could build that, make a shadow in their repository, cross repository shadow, and build for open Solaris on that shadow but track the changes we're making to the source code. Groups are collections of packages. And this is one of the key distinctions in Canary, is that our way of collecting packages is source and binary. Most other instances I'm aware of are, here's a list of names of packages. And maybe you'd even track changes to names of packages, but the client system is going and processing this list and deciding what to do for an individual system. What we do instead is we say, you are building a group. Here's a source. It's a recipe just like for a package. It says, I want to add this package and that package and another package. And it goes and looks in the repository and adds the packages and records the exact versions of those packages and components. And so Group My OS, version one, is going to say not just a few names of packages, but internally in the repository, that resolves down to the exact contents of every file installed on the system. So let's say that your operating system is derived from our PathLinux. And you've only added three packages and a plus our core basic operating system. Then we come up with a security update that affects you. You build that group again, you cook it again. It references new versions. Now you've got version one and version two in your repository. When someone wants to update, they say, I want to update to the latest version of Group My Appliance. And in our Group My Operating System, Canary then provides only the changes that are actually... It calculates the full changes between those two versions and applies those changes to your system. So it's a lot more like source code control. If you are tracking TIP and you do whatever your source code control system is, you merge up to TIP. It's the same kind of operation on your local file system. You're applying the changes, not just pulling down a whole load of new packages in your local file system, regardless of current system state. So a group defines a consistent set of packages, and this allows you to have a very nice QA and release process. You can build a package, the developer can look at it, and say it's good and commit it. Now you can have testing, or QA, and take a group and we have a way to move a group through the process of doing test and QA. And you can define whatever your process is, and you can move it from stage to stage. It's the exact same contents each stage along the way. So when QA is done and says, this is a good slice of the operating system, we run whatever tests we want on it, which are going to be different depending on what you need, then you make that available to the end user. Now, when I'm building an appliance that only I am using, it's something very simple that includes, say, a mercurial that I'm going to run as a DOMU on a Zen server. All my QA for this for myself is to compare the differences between them and just look and say, was this the change I wanted to make? But if I'm building a commercial product where you really need to run a whole test suite against it, that would fit into that place in the process. So it's a flexible construct. Package inspection, there are a few core things that I want to talk about. We have the ability to look at essentially all the elements of the package and look and see what's in it and what's different between different versions. One of the very useful things is file versions. When you build a binary package, you build the second version, first the first version, then the second version, the versions of the files that are stored, if the file hasn't changed, the file version in version two of the package is still version one of the package. So it's not just that the contents are the same, we actually say it is the same file. And so if you've rebuilt it and the binary has changed with a man page hasn't, the man page will actually point to the old version. And this keeps going. So you can look at a package that's part of a, you know, long-running maintenance stream and there's been some development behind it. You can see all the history of the development where things changed by looking at the exact version of each file in the package. File dependencies are another critical thing that we can display. When you build a package and it has a dependency you didn't expect, you want to know why this new version of this package dragged in a new dependency. You can easily find the file by asking, can I just show you the dependencies for each file? You know, pipe that to less and search for the exact dependency you want to know about and see what file it's in. And then you can determine, is this something I want or something I want to fix? We have a Canary RDIF command, which just displays what's different between this version and that version of the package. And the default output is fairly concise. You know, files changed, dependencies changed. Then you can ask it to give you details about exactly what changed, and it's a diff-like output. And the last thing I want to talk about for package inspection is the repository browser. Because the Canary repository is essentially a web service, it's almost free for us to provide a web front-end so you can click through with a web browser and inspect the package by browsing it. Click into the component, look at the file, download the file. That's a very convenient way to get things like our build logs. If you just want to see the build log for a package, you just go look in the repository, click on it. You can either install it on your system with the Canary command line, or you can look at it in the web browser. There are a couple things I want to say about testing, because I believe that testing is part of the process of building a package. The first is I've mentioned that Canary makes rollbacks reliable. And they also make testing easy, because it's not a problem to install the new version of the package out of your RMake repository or off of your development label on your computer. You try it out. If it doesn't work, it's very easy. It's one command to rollback your latest change and you're back at what worked before. The other thing is I've mentioned several times that Canary is when it's applying an update to your system, it's essentially a merge. It's not changing files that haven't changed. What you can't do is go into the file system and start just changing files, and then expect when you do an update to a new version that is just going to blow away your changes. So that's the one thing that might be different in Canary testing. You can't make random changes to files, and just assume that the next update operation is going to revert whatever changes you made. It's still possible to fix that if you do it. It's just not a good testing practice with Canary. So these are places for more information. I don't know how we're doing for time. I'm right on at 45 minutes. I have time for questions. One thing I want to mention is if you want that two-hour-long presentation thing is a link, I have that presentation up, and I want to show you more technical examples of what Canary recipes look like and what the process looks like. So I'll start with questions. I think I'm supposed to do this. Oh, well, I'll just repeat the question. Do we support soft dependencies or alternatives? No, I've tried to make... This is very much my influence, but I've tried to make dependencies be very specific and have a meaning that can't change. So we don't have virtual dependencies, like provides generic capability foo. We've had a few requests for things like that, like provides SMTP, but to my mind that's really provides something that listens on port 25. And so we haven't yet added something, a dependency class for port listener, but that is something that would make sense for me from my standpoint to add. We haven't... One of the reasons not to do dependencies that you would expect to be resolved by multiple different applications is that when you're building these groups, we often do automatic dependency resolution. And so if one time you cook the group, it was resolved by one package, and another time a different package, that would make for unstable groups. So we have... You could actually package multiple libraries that provide the same soname and the same symbol version, and then it would have to pick between them. We had a case of this before I put in all that handling for scripts that used LD library path, where OpenOffice was providing libstandard C++. And so when we were trying to build something that required libstandard C++, sometimes it was trying to install the version from OpenOffice, and that wasn't working very well. So we have chosen not to implement that in order to have a stable update string. There's two of you. I'm sorry, stay again? Sure. Okay, how do you... Is it really asking how you bootstrap working with this? We built an operating system called our PathLinux that is built with the Kanari technology. We don't try to support mix and match between different package managers because dependency resolution doesn't work in that environment. So you couldn't have Fedora Core for your operating system and Kanari for your applications. That said, I'm very interested in seeing other operating systems running on top of Kanari. And as I said, it's just imported to OpenSolaris. I believe there are people who are starting the work of actually building OpenSolaris with it. The other half of the bootstrapping problem, another thing I didn't get into here is the fact that Kanari has built-in support for cross-compiling. And in fact, when we build our operating system, we do a native cross followed by a bootstrap phase all driven by Armake. Armake is able to look at how the packages are designed. It automatically breaks, build loops, and does builds until it gets to the point where it can start solving dependencies cleanly and then builds the whole operating system. And that's a fully automated process. And that tool is OpenSource. It's available to anyone. People have used it to try out PowerPC builds and I think we're going to see more other architectures built with Kanari now that there's getting to be a little bit more interest. We tested the cross-compile by doing a fully working charot in PowerPC. It just hasn't been the focus of the company at this point to do anything other than X86 and X8664 because that's what our customers are using. So we focused our attention there. And you had a question, too. What kind of packages can it build and for which distributions? The packages it builds are Kanari packages that are in a Kanari repository. Right now, you're building basically for our path Linux or foresight. But there are... The other way of looking at this is every time... I said I wasn't going to talk about building system images with our builder. We have this web site that you can go to where you can create your own repository and build your application in there. We have something like 10,000 of these repositories that people set up in which they're building their own operating system. And then some of them do mash-ups that combine aspects of multiple repositories. Because Kanari is a distributed repository system, your operating system can contain components from multiple repositories. And there are... So from that standpoint, your packages can work in asterisk now, which is built on top of our path Linux. They can work in OpenFiler, also built on top of our path Linux, like I said, I'd love to see other base operating systems besides our path Linux as a core built with Kanari. So if folks are interested, please do talk to me afterwards. So as a proof of a concept, you mainly implemented that on this restricted set of applications so far, or do you have some other experiences with other platforms so far? How much time does it actually take to recall the new spec files or how do you call them? And another question, based on your experience, what share of typical projects can be actually covered by these means and methods you describe like automatically configuring, making store and stuff like that? So how much time does it take me as a maintainer to convert to Kanari?  The answer is not a whole lot. We're maintaining two streams, the R path Linux 1 and the R path Linux 2 beta. We have basically four and a half people doing that while implementing new features and supporting customers. When we were just starting, part of my time was developing the build side of Kanari. Part of the time was actually building the OS, and then we got two young folks' interns and they basically finished the OS in six weeks. Now Ken van Dijen is sitting up front here. You should talk to him afterwards because he has experience building whole OSes on an almost entirely automated basis. The GNOME developer kit is an excellent example of that. I say I'm out of time, so if you have more questions, please come talk to me. I'm here for the next talk. I'd like to plug it, package kit, but then after that I'd love to talk to folks more about Kanari. Thank you very much.


It's an even better day to celebrate collaboration, and it's the best day ever to celebrate global solidarity. Today I want to welcome a special guest who is with us, Van Swadegog, Senior International Development Officer, Inclusive Growth, Governance and Innovation in the Partnerships for Development Innovation Branch of Global Affairs Canada. For the special announcement that Global Affairs Canada will collaborate with Kairos and our wonderful global partners to implement a five-year project, Women of Reward. Now this project is going to support grassroots women's program in Colombia, the West Bank, in South Sudan, the Democratic Republic of the Congo and the Philippines. And in this five-year agreement, Global Affairs Canada makes a $4.5 million contribution committing Kairos to raising $1.3 million for the match. As you know, for some of us this has felt like a very long time coming. Some might even say eight years. And what our global partners have demonstrated is creative resilience and profound solidarity. The OFP and WIAM, ECU Voice, the South Sudan Council of Churches' Women's Programme and Hedita Delegies with very little resources have transformed women's lives. And in their different contexts that are common in the presence of sustained conflict, they have seen women not as victims but as human rights advocates, not as recipients of charity but as potential leaders in the establishment of peace with justice in those countries. And it is these programs of psychosocial support, of human rights training, of support to women's participation in peace processes that will receive these additional funds up to a level of 100,000 in a year. Ours has been a journey of mutual solidarity. Just as much as we have supported global partners with funds and advocacy, they have supported us, giving us clarity and strength of vision to stay the course for bold social change. And this solidarity has woven into this project. As well, these five women-led movements will engage with one another and with the networks and movements of CHIROs to strengthen analysis, to build capacity, and to develop courageous best practices. So today we really want to express our deepest thanks to our partners for journeying with us, the members and the networks that have supported us, the partnership staff working with partner colleagues who have developed this dynamic project, and finally global affairs for their support of grassroots women's-led program and for their commitment to gender equality and human rights and for their collaboration with CHIROs. We have long awaited this day. So I'm now going to turn it over to Francois to say a few words and then we'll get a glimpse of our wonderful partners. Good afternoon, everyone. Good afternoon. It is my great pleasure to be here today on behalf of Global Affairs Canada to participate with you in the launch of this exciting new project, Women of Courage, Women, Peace and Security. As you know, Canada places gender equality and women's and girls empowerment at the heart of its international assistance. Canada's feminist international assistance policy recognizes that supporting gender equality and the empowerment of women and girls is the best way to build a more peaceful, inclusive and prosperous world. Yet, as you also know, in many regions around the world today, conflict and its consequences impedes sustainable development and erodes the peace, security and the protection of the rights of women and girls. At the same time, we know that when women are involved, peace and post-conflict processes are more inclusive, more equitable, more sustainable and more effective for everyone. Canada's National Action Plan on Women, Peace and Security, renewed in November 2017, demonstrates Canada's continued commitment to ensuring that women are active agents in the development of sustainable interventions in conflict and post-conflict states. In this context, Global Affairs Canada is pleased to support CAROS in its new Women of Courage, Women, Peace and Security initiative. I know in a way it's much enhanced, I guess. You've had a program already, but we are pleased to permit a major enhancement within this new project. This new Women of Courage, Women, Peace and Security initiative is to be implemented in, as Jennifer mentioned, in Colombia, in the Democratic Republic of the Congo, in the Philippines, in South Sudan and in the West Bank. Global Affairs Canada will provide funding of 4.5 million over five years. That's also an interesting period. It's important to provide some stability, which will support the work of five grassroots women-focused organizations who are expected to reach more than 35,000 women and men, mainly women, including 9,500 survivors of gender-based violence. The five local partners will partner... I'm from Partnership Branch. We like to repeat the word partners. And the focus is correctly, and it's nice. We're going to get the message that focus is correctly put on the partners, because they do an amazing work. So the five local partners who will partner with Kairos to implement this important project, each have a long history in their respective countries and territories. Their expertise and grassroots connections will ensure that the Women of Courage initiative benefits those women and girls most in need, enabling them to heal from the effects of war and to become peace builders and defenders of human rights. Kairos has partnered with each of these women-focused organizations for many years. And as you mentioned, it's been a mutual, supportive effort and experience. And Kairos's expertise in women's peace and security and grassroots level intervention positions them as a strong Canadian partner for this work. So in dealing with the important challenges to peace building, reconstruction, and development in the countries and territories of intervention, the combined experience and expertise of Kairos and its local partners represents a major asset. So once again, congratulations. We look forward to our continuing partnership for this important Women at Courage, Women in Peace and Security initiative. Thank you. Back our gratitude and thanks to his colleagues at Global Affairs who worked so hard on this project, but also to thank him personally because he has been persistent. He has been creative. He has helped us to build to the place that we are now and we're just so delighted that we can go forward together with this project. So much thanks. Thank you. So hope that the special guests that we could also bring would be our partners so that they could be with you. But we're going to try to do the next best thing and offer you some of our partner voices who have sent them along to be part of this time. And then you'll actually have an opportunity to interact with the partners in a different way this afternoon by visiting and learning about each of these programs. And so we're ready to go, I think, with the video so that we can hear the partner's voices firsthand and it's starting with Bernie from the Philippines. We are emboldened by a partnership that is not self-serving but on the basis of empowering women and communities to make human rights work for them and which will benefit all. The project's relevance and urgency is demanded all the more as the country's human rights defenders face violent attacks from the state security forces. This partnership will definitely strengthen the capacity of women human rights defenders and militarized communities. This will not only be monumental for communities of women human rights defenders in the Philippines but for the Canadian government as well that provided financial support to this project. Let us stand together our best wishes for the successful launch of the Women's Peace and Security Initiative. I feel like let these women of courage not only be within Kairos Canada but we need also other angels to learn from what Kairos Canada do to women. Kairos Canada is actually encouraging us women and I'm one of the women that felt like I become courageous because of that name Women of Courage because I've seen some photos of the women and what Kairos Canada do with the women. Kairos Canada is really accompanying the women to become courageous. I'm Yolanda Becerra Vega, the Women's Popular Organization a human rights defender organization in Baranca de Armeja, Madalena Medio Colombia and for us the project that has been approved and that is currently starting its execution is very important because it is to keep hope to strengthen ourselves for the construction of peace from the territories healing all the wounds of death that have been left in our territory but also all the wounds that we have in our bodies women for the reason of armed conflict. Thank you for your support Thank you for believing in us Thank you for walking with us because not only the economic accompaniment but also the political and the human that makes it possible for life to flourish in the midst of these contexts that we have in Colombia. The financing of the FAMP project will not allow the Bel-Henri City Council to improve its field intervention capacity through education, training, and awareness of women so that these women can access the resources of decision making and so that these women can participate in the actions of peace consolidation. Also, for the beneficiaries, the project will allow the beneficiaries to end the fear by denouncing the different cases of sexual violence and other violence based on the child in women and victims. This will end the culture of impunity which has led women to fight today. My name is Lucie Teljiye and I'm the project coordinator for the Women Peace and Security Project. And I'm Tarek Alzubri, the project manager. We are so excited to begin our work on this project through which we will help empower women, especially those who are suffering and having suffered from domestic abuse through providing trauma healing and coping, mediation and training, economic empowerment, through job creation and legal aid. Through this, we hope to inject women with hope and begin transformation process from a life characterized by marginalization to one by choice, freedom, dignity and empowerment. Thanks a lot for your generous grant. That we pledge our hearts and our hands and our labor in a common bond that we imagine this possibility of transforming the world together. So we are so delighted to take another step forward in this walk and we promise them not only our financial support but our continued relationship and perhaps as important our strong voice speaking out on issues that affect them but also speaking out in our own country. We will stay the course in our advocacy because that's who we are. So thank you. Thank you for this moment together. We wanted to share this with you and we're so delighted that we were able to do that.


Hi, this is Pastor David Rosales of Calvary Chapel of the Chino Valley. I've been using social media, especially Facebook, for several years now and have found it to be a great way of sharing with many people about the goodness and love of the Lord. What a great tool social media has been for keeping in contact with friends, not to mention the making of new connections and also for the dissemination of the gospel worldwide. What a blessing it is to be able to share right now, live with so many who not only attend our fellowship, but also with those who are listening throughout the United States and even in other parts of the world. I'm truly blessed to be able to share with so many through this media. With that said, something has attracted my attention that I thought would be good to address. It's the growing rudeness that I see in some of the comments that people post. While I understand that people have their opinions and believe themselves to have not only the liberty but also the responsibility to let everyone know how they feel about things. It seems that some have failed to realize that not everything they think is worth telling other people about. I get it. Social media is an outlet for people, all people. And there will always be those who want to show pictures of their cats on a fancy dog chasing a ball or their latest breakfast or dessert. That's fine with me because for many, that's something that matters to them and nobody forces me to look at their pictures or to comment on their dinner. Though I'm not a cat person, I do appreciate the love someone can have for their pet and respect that they want to share this with everybody. Those who aren't interested don't need to look at the pictures. That isn't what concerns me. What concerns me is the lack of civility that some people fail to exercise when they disagree with someone and the way they feel that their opinions are not only correct but that it's their duty to express them but they get rude when they're corrected for any error that they have embraced. As a pastor, I've been in ministry for over 45 years and at this point I've studied and read my Bible, commentaries, books and articles for many thousands of hours. I've taught classes in Bible college, mentored pastors. I've given over 8,000 Bible studies ranging from home studies, church services, retreats, conferences and hopefully I've earned a bit of respect for the years that I have spent in ministry. I say this to emphasize that this kind of things mean something in the kingdom of God. Of course, I'm not saying that I am not open to correction. I am saying there are those who seem to think that because they believe something they have a right to correct any with whom they might disagree with even if they have no experience to present as credentials. I should say at this point that I'm not speaking on behalf of myself. To be honest, I don't get many rude comments on my Facebook live programs. The overwhelming number of comments are kind and positive. I'm not speaking on my own behalf. What I'm really speaking of is about the comments that reveal such mean-spirited and self-righteous attitudes that I see posted on pages of friends of mine who like me are simply sharing a quote from a well-known Christian leader or are encouraging people to live for Christ. One friend in particular gets so many odd comments on his posts that I have taken to writing him and asking him why he keeps posting seeing that so many know better than he. His answer is simply that he just wants to encourage people in their walks with the Lord and such comments seem to come with the territory. I've told him I admire his patience. It seems that we are in the age of instant experts. After all, if we have a question, we can simply ask Siri or Google an answer immediately. We know much more than the average person on that subject, including our pastor. For many today, spiritual maturity is simply a Google away or supplied by Siri and not the spirit in the word reality. As spiritual maturity comes through years of steadily, obediently and consistently following the Lord, studying his word, walking with spiritual leaders, serving in our churches, learning to love people. Spiritual maturity comes through prayer, pain, trials, brokenness. It comes through struggling with the Lord over things that we don't understand and us ending up like the Old Testament patriarch Jacob who after his encounter with God ended up walking with a limp for the remainder of his life. It was in his wrestling with God that he was broken and it was then that his name was changed from Jacob which means supplanted to Israel which means prince with God. Spiritual maturity is earmarked by love and love is very often revealed with humility and it is with this attitude of love and humility that any question should be posed to one another and should especially be present when we go about correcting one another. In the book of Galatians chapter 6 verse 1 Paul gave instructions concerning correcting an erring believer. He wrote, He went on to say in verse 3, Of course there is a place for correction and yes there is a time to expose sin or error. We're not to simply accept anything that said in the name of Jesus and wisdom and discernment is at an all-time low in the church. This has been manifested recently in the well-known news story of a so-called evangelist who's asking his donors for $54 million to purchase a new jet for his worldwide travels.  This kind of practice is revealed for what it is in both the Old and New Testaments and errors like this are to be openly exposed and completely rejected. Still, how we correct one another and how we go about voicing our beliefs requires humility, accuracy, orthodoxy and love without speaking the truth and love will not be successful in warning and encouraging those in real error. If you have the tendency of correcting others if you desire to correct people on social media that you disagree with then personally speak to them if possible if not perhaps you could privately message them share your concerns ask them to clarify what you seem to be hearing them say no one is above correction but courtesy and love go a long way when approaching error or bringing correction please remember that as Christians we are to be known for our love for God and others this means that we should be kind towards one another when we disagree with one another This is Pastor David Rosales of Calvary Chapel of the Chino Valley