I hope this time is going to be a long afternoon for all of you, since 2 o'clock, I am sure you would have a good experience of the speaker and the speaker before me. So my name is Amit Sharma, I am the Solutions Architect with Amazon Web Services. Anybody who is not aware of what Amazon Web Services is, no, alright, anybody So Amazon Web Services is an Amazon.com company, it's a separate business unit of Amazon itself and we are purely into infrastructure web services. So when I say infrastructure web services, it's purely around offering storage, compute, networking, all of those, as a pay as you go model for our customers for them to build their sophisticated, scalable and secure web applications. And how many of here are purely technical and how many are from business side? How many of you are from business side? I should not be for you, and others are purely technical. I'll just wait. So for the non-pay folks who are from business side, I'll just try to put in some of the business stuff as well so that you get some context around it. So I was given this agenda on infrastructure automation, so I'm sure Jasveer also spoke about it as to how NDP has been using the puppet around the entire infrastructure and application automation, etc. So my topic will be primarily around how you achieve this automation in Amazon Web Services. So just before I start, there is something called an Activate Program that we have. So please register for that. It's open for everyone. So it gives you a lot of benefits like we give the promotional credits. You also get some 30-day trial for the support, business support that we have. We do a number of trainings. We do a number of office hours where customers of similar domain can come and do a brainstorming around that. Plus a lot of special offers that we keep on doing that, so just register for it. There is no charge for registration as such. So a quick agenda. It's a bit long agenda, so please bear with me. Mitesh from Nightingale Springboard actually told me that keep it as informative as possible, so I'll try to do that. I just hope that I don't bore you with that doing that. I'll talk about AWS and Automation, and there are multiple services, Elastic Beanstalk, CloudFormation, Observes, which allows the customers and startups and in fact customers of all sizes to do automation to the maximum extent that has been possible. And this is totally integrated into Amazon Web Services. So we'll talk about pros and cons here, all these three terms very frequently in this session. Plus I have a couple of demos on Elastic Beanstalk and CloudFormation, so that will be interesting for the guys coming from a technical background. And then of course there is our question. Q&A, so please interrupt me whenever you want to. No problem. Quick overview of the Amazon Web Services products and services. So AWS, we do not categorize our services into IaaS, PaaS, SaaS and all that because we believe the boundaries have blurred and there are no clear distinctions as to which service will fall in what domain. So as you can see, we categorize our services into networking, compute, storage, databases, applications, etc. So during the course of the slide presentation, I'll cover some of those services in more details. Now since you are startups, I'm sure a lot of you won't be listening to your customers very seriously and your customers would always say that give me a fast application. At the same time, give me a service which is always on as lots of features related to it. So you will want to put in as many features as you want into your services. And finally last but not the least, they will also respect the law of customization and personalization on your web services. But it's easy to say but how do you normally do that? And how does that fit into the overall context of automation? So before we jump into automation, so let us see automation in context to the larger picture. That is when you run applications into cloud, into say Amazon web services or for that matter in any of the cloud environment, there are certain rules or certain approaches that you have to take to create your application. So you cannot just take an application running in a physical environment and put it into cloud and expect the benefits of cloud also to be visibility. That does not happen. So that has to be taken very seriously that when you create an application and put it onto cloud, there are certain rules that you need to follow which technically your application may just run if you just pick and drop into cloud. But that will not give you those benefits. So what are those rules? Let us first see that and that will actually set the context of automation as well. So the rule number one is serve all the web requests that you want. Every request that comes out of your application should be served. How that happens, I will not go too deep into the whole Amazon web services and how it allows you to do that. But customers like NDDV and others have actually leveraged that extremely well. They leveraged the entire global infrastructure to make sure that none of the requests that come onto your websites are dropped. Second is, serve the request as fast as possible. The color combination may not be too great but you will see the approach. So choose the fastest route. So many DNS services across the board have these features of latency-based routing and routing to the nearest pop, etc. So a lot of startups actually leveraged that. So we are talking about the startups like Instagram, Pinterest, Netflix, etc. So they all leveraged that so you can make sure that the request is routed to the nearest pop. So offload your application servers. Now this is a bit of an abstract concept but at the same time extremely powerful that if there are certain services available then don't load your compute nodes to give out those services. In this case for example, content delivery networks. I am sure you have heard about what CDNs are, content delivery networks. So try to offload the static and dynamic content to the CDNs rather than letting that go back to the compute nodes.  Next is the caching. So this again is a bit of an under-value concept that we have seen across the table. So I keep on speaking to a lot of customers in North of India and caching is something that is not given as it should be. So caching can happen at every layer. So CDN is the caching at the web layer. Then there is caching that is possible between the app and the database layer which is a last-minute cache, radios and all of that. So there are services available so we advise our customers to leverage that. Apart from that, single digit latency is where it matters. So this is more in context of the database. So when database is scaled, it becomes extremely important that you're going to put everything on to a MySQL or a relational database. So just think about putting some of that load out to some of the newer skills like the MongoDB and some of the other services which are available. Very important concept, not very easy to execute though, but it's all the big companies like Shazam and all they actually leverage a new skill for their unique use case. Whatever Shazam does, you make it here, a song and it will actually go and play. It's so strange, right? None of the relational databases across the world will be able to handle that and they leverage all the new skills for that. Next is the scale. So scale is a very important concept. So new applications may work extremely fine for a few hundreds of thousands of users, but when you actually scale to much larger numbers, say millions of customers and all, the whole architecture needs to be defined according to that. So scale up is one option, scaling out is another paradigm that comes in the cloud. So don't try to jack up your compute loads from two loads to four loads to eight loads and all that. Try to spread that load across multiple compute loads in parallel and when you don't need them, just shake that load back to the pool of resources. Then it's for horizontal scaling. We have this concept of auto scaling, etc. which allows customers to easily implement all this. Simplify architecture with services. Again, now if you have been using some of the services like queuing or some of the database services, you can either build up those services on your own on some of the compute loads or you can just offload those to some of the services that most of the cloud providers would generally have. So queuing databases are some of the load-hanging foods which you can offload in the cloud. So this is a nice thing about that. Instead of focusing on your business, you sometimes tend to focus more on creating a service for yourself. Whereas in a cloud-like environment, you can actually focus more on your application and just leverage a service which already gives you that as a service. So your whole point is that you move away from the service and move into the service. Services are, in most of the cases, do not have a single point of failure. They scale extremely well and they have security, etc. they train as part of the service. Next comes the automation part of it. So as you can see, out of the various aspects of designing your application in a cloud, automation is just one aspect. Very important if you really want your application to scale to that level, so automate for operational management. And this is true for almost every cloud or at least if you are evaluating a cloud, you should keep these things in mind that anything in the cloud should be automated. What that means is, launching a compute mode, attaching a storage, creating a storage, increasing the size of the storage, creating new routers or new routes, etc. should all be an API goal. And that is what typically happens as you can see for a few years in various databases. Everything just becomes an API goal. And all of these APIs are available through SDKs across various programming platforms like PHP.NET, Java, etc. So that's a very important aspect. So if you are planning to go for a cloud-based infrastructure, make sure that you have full visibility of what things can be automated or cannot be automated because this is the holy grail or cool point of going through the tool. So these are some of the services. As I said, this is the prime agenda as well. Welcome to those. So OpsWords, CloudFormation, Beanstack have a varying amount of flexibility into them and they are made for slightly different purposes. So I tried to convey this to all of you. And then there are some other aspects like bootstrapping, auto-scaling, cloud-mode, etc. So none of those two actually leverage that very important asset. So the whole concept is that to create a base minimum image of the operating system and let that machine, when it comes up, takes its character at the very last moment. What that means is the machine should by itself not be hard-coded on whether it's an application server or it's a data-based server or it's a web server. It should get its character at the very last moment. That's the whole idea of putting your workloads into your cloud. So that is called bootstrapping, auto-scaling, and some of the OEMs like Red Hat, Centro as Ubuntu now officially support these concepts in the cloud-like environments. Lastly, there is something called a sort of a cloud provider. For example, they will have their own way of billing, etc. So that is extremely important for you to understand whenever you choose that. So there are, in Amazon, there are multiple ways of doing that. I'll not go into this. This is both not the business cases as well. But there are, like, for instance, this reserve on-demand which allows you to predict your workload and get the maximum plan for your path by committing to some of those plans. So let's now jump into the automation aspect. So why automate? What can we automate? This is important. This is what you would like to understand here. And then see what are the tools and methods. So this was the third factory way back at the moment, 100 years back. So people used to manufacture their tasks, etc. and assembly lines, extremely good concept. And assembly lines actually help to create a commodity product, out of a luxury product, right? Drop prices so that it can be mass produced, sanitized, excellent idea and actually got something out in the market very nicely. However, assembly lines had their own problems. Those were all human-driven, right? So there were all the scope of errors, etc. And the quality was also somehow not consistent. So two subsequent tasks which saved assembly lines may not have the same characteristics. But apart from that, only black, you know that typical, the very famous comment from Henry Foo, you can order any color of the car as long as black. So fast forward a few years, not few years, 100 years and now we have robots manufacturing most of the tasks and that is where the automation comes in. So let us extend back into IT as well. So these are couple of my colleagues actually, they are racking the server. If you have seen a server, it's a 50-bit server. So they are racking the server, nothing wrong with it. Only issues that this is an upside down server. Right? So they are trying to put it upside down and show the ramped up in out of a slot by now. So let us quickly look at some of the pretty blocks that I'm not going to ask. So either there's EC2, for example, or as virtual servers, so we can select from the whole variety of servers which are available in the cloud. Route 53 is the DNS servers which allows you to register on the main and then use Route 53 to solve all the DNS requests, etc. Auto scaling is for horizontal scaling. So depending upon the node criteria, etc. it will keep on launching more and more instances and when the load comes down, it will formulate some of the services. So this was the compute and networking mix of the storage. So elastic block store is a block store as you can see from the nature of it. So you can attach it to your compute code, format it and start using it and you can format it to whatever file system you want to use to create it, etc. S3 is an object store. So it's a storage for the internet. There is no limit to how much data you can trumpet there. It's a simple storage service. It has 11, 9 store durability. It cannot be mounted like elastic block store but at the same time it has huge capacity both in terms of storage as well as how much throughput it can handle. Next is the instance stores. These are the direct attached storages which are available within the EC2 instances. Those are available in nature. Next are the databases. So RPS is the relational database service. So we have MySQL, Loretto, SQL Server, Postgres. All of these options are available in RPS now. Panama DB is a lower school, very low latency and highly consistent database, lower school database that we have. You don't need to provision the capacity and data. It just scales automatically depending upon the load that comes in or you can actually find your own requirements. Or you can run your own databases on EC2 for example, DB2s and all that. Now I spoke about the automation. So all of the three aspects that I spoke earlier the storage, computing, databases, etc. All of those are enabled or available across multiple platforms. And there are also integrated developer environments some of them will be show studios and Eclipse so that you don't need to do standalone development it can be integrated into those environments as well. Right, so how can we come to B-Stock? Elastic B-Stock. So simply say Elastic B-Stock, what it does is it takes the B-Stock you can upload your code. So suppose you have what warfine created for your web application or for a PHP, if you have a PHP app it will zip back that PHP app and upload that into B-Stock and it supports multiple platforms like PHP, Java, Node.js, etc. and once you deploy it on top of that, what it does is the host is already there, the operating system is already there. In fact, right until the application service is already there and your code just sits on top of that and that's it and your code will be up and running in less than 10 minutes. So you don't need to worry about launching a load balancer launching the EC2 instances, launching the storage and all that. So that entire aspect of launching a web application is fully uploaded to the service. Now you know that this is typically called platform as a service but we don't officially call that so we call it Elastic B-Stock. Now the thing here is that what it might differentiate against other pass-like offerings is that you still retain the full control of the underlying infrastructure. You can still log in to each of those EC2 instances that have come up do your own thing in there, change the storage or whatever you want to do in there. Now the context is black on black but what it allows you to do is it can maintain multiple versions of the applications. You can have version one, version two, version three, version four and so on and at the same time you can have multiple environments in an application. Why would you make that? Because you can have an application and you can have a dev test staging and the production environments for the same application and now of course can be maintained into this and if you want to switch from one to another it is as easy as swapping a dual or if you are not happy with the version four of your application you can always go back to the version three. That is not benched into WinStop, you won't need to do anything extra. And you can also save the entire environment configuration so that that becomes repeated. There are the CLI options as well and this is also integrated with Git so if you are already publishing your coding to Git then that Git repository itself can be used into WinStop to launch the environment. But these are some of the aspects that you can control. You can control the region so you can pick up the region whether you want to launch it in Singapore, you want to launch it in Tokyo or whichever region. Plus you can also select the container type. It can be PHP, Java, .NET, whatever container you want. It can be across a single server or it can be a fully production workload across multiple instances and all that and the databases can also just come out as part of this. So this is how what Elastic WinStop will launch in the background. It will launch one local instance, so this is a local instance and there are like 20 single instances which will get it in that code and the auto-scaling will automatically be configured on it so that you won't need to do that. And when the load increases the number of servers will automatically increase and shrink depending upon the load. And this application will automatically be available on something.plasticwinstop.com which is the URL for your application. You can also snap it to your own URL using the canonical URL. So these are some of the prerequisites for creating a CLI based environment. It allows for a zero-town tent deployment so as I said you can have multiple environments for the single application and you can switch between the various environments with the click over button. So if you're having with a staging environment and you want to now put it into production there's something called swap neurons. So just with swap neurons your staging environment will go into production. What is the cost of WinStop? It's absolutely free. So one of the things that get launched last part of WinStop is charging. So did you get a fair idea of what Elastic WinStop is? So I'll show you a quick demo. So it's a pre-recorded demo. I do not have any connectivity here but I think it should be a good idea. Now it's in the console. Pick up the relevant service in there. Give that service a name. Here you're selecting a platform. You can see there are multiple platforms. You can pick up that platform and select whether you want to do a test environment or you want to do a professional depending upon that. You can pick up that and in this case we selected a sample application. So in this way not too much if you just display a sample webpage. You can also launch your database along with that. Selecting an instance type. What size of an instance do you want to use in there? And what key pairs you want to attack? You can use along with that. And that's it. So now your application has been put in there and this is automatically creating that entire infrastructure in the background. This is a SKHT path. You will see all the events that are happening in the background. If you show a local as a being called, how most of them being configured, these are just being called, etc. So from that to this it will take about 10 minutes. Once that is done you will actually be able to see that all the events are successful. The status of the application is ready. Now clicking on that. So this is the sample page. As you can see that something got elastic green stock of the URL has come up. Now what we are going to do is replace this with your own custom code. So this is index.ahp.  So we are going to zip that into a zip folder and upload this and update that green stock application that was just launched. Now you are loading a new version of this line up. Today you will be able to see all the versions of the applications. Now once this is deployed, refreshing the same URL you will see that this application has been updated in there. So this application comes up. So as you see the whole value proposition of green stock is that as a developer you don't need to worry about the underlying infrastructure. Paid storage, networking, load balances, computes and all that. Just push your code and let the green stock do everything for you in the pack. So basically it's a template for the blue stock. Does it provide terms and provide templating functions for blue stock like we can copy the templates? Yes. So these versions are nothing but templates. There is something about parameter groups in the background which allows you to say that I thought to always launch my servers on this particular capacity. So that becomes a template. Are you templating a green vendor or more on Amazon? More on Amazon. Yes, so in Amazon we do not have a concept of template. Yes, I think all machine images. But the whole idea of green stock is that you don't need to worry about images. You have your code and that is what you want to focus on. Just push that code on the green stock and let it do everything. I mean you can say that the template for the green stock gives you more time to say how to scale the database so to be able to do a lot of services. Yes. What is the point of application? You want to templateize that. So I'll come to that. So CloudFormation is the service for that. So there is a different level of abstraction that is there between all of these three services. So green stock, CloudFormation, Obstructs has a different level of abstraction and at the same time it has a different level of granularity under what control you can have on all of these. If what you told, you can create, you can do that with sequence terms like rd3, create, work, generate, configure. So it's all in one word. Correct, so it's easy for you if you know those terminology. There are a lot of things like recoverings which you need to understand. That's the whole value proposition of green stock is that you don't need to do that. You have your code just upload to green stock and let green stock take care of the thing. So you can always do it on your own. So you can launch and you see to attach a notebook and it's a code it and do whatever you want to do. The thing is that's an effort. You can avoid that by using these two. Yeah. Yeah. Correct, correct. No, so if you do not do vertical scaling, it will keep on launching more and more even micros depending upon your configuration. So it's always important that you take a estimate initially that maybe T1 micro may not be good enough for me so let me launch it with an urban media or an urban launch. And see how that spans out in terms of node and all.  Sorry. Now you can mix and match because it will try to create a homogenous environment. Now comes the cloud formation. So cloud formation, it's again an abstraction at another level wherein what it allows you to do, you can create a JSON template of the entire infrastructure. Right? So in elastic things to create an application and throw it at the service which created it. But on the other spectrum you can say that I want to control my entire infrastructure from the cloud. And that is what the cloud formation does. So it makes the infrastructure as a code. So you can actually write the JSON template, I'll show you some of the samples in here. So you can create a JSON template, JSON file of your entire infrastructure and upload that. So you can even define some of the application stacks scenarios in cloud formation. So this is the stack. So suppose this is your infrastructure in Amazon. So you are using three clouds. So there are multiple services that you are using. Right? And imagine that you have a requirement where you want to redeploy this environment from Singapore into Tokyo as well. Or you want to create this environment in Ireland as well. Right? One way is that you keep on doing this manually one by one. Another is that you create a cloud formation and create out of it.  Without you having to do anything manually. So there is a company in Delhi who do this quarterly quiz competitions. So which are online coding and all that. So they also need an FP setup. They need like 30-35 servers which are doing only this, only the cuisine competition, the code evaluations and all that. So they don't do all of this manually. So what they do is they have a cloud formation template. They launch it and they create something similar to this. And they are ready with the coding competition and after 15-20 days when the competition is over they just terminate the stack and all of this gets related automatically. So that you don't run off forgetting a particular resource being released and still getting paid. So this cloud formation template is good when you want to have infrastructure with capital becomes repeatable. Right? So let us see what a template is. So the template can actually be stored in Git, Subversion or whatever the code requires doing this. You can create multiple, repeatable and mark this out of it. So let us do a quick amount to me of cloud formation template. So this is Jason. We recognize this of course, right? So this is Jason. So you can define, I want to launch this kind of resource with these kind of resources with these names and these particular properties of this particular resource. You can specify, launch for this, improve this key plan, improve this API and not this particular type of instance. Similarly, you can define multiple restrictions and so forth so that you can restrict the user that always launched a T1 micro and never launched more than T1 micro. So you can restrict that in there. And apart from that, you can also get an output. So suppose our infrastructure has been launched over in EC2 instance, you would like to know that you are allowed that instance so that can also be extracted out of the cloud formation templates. So that was what aspect, as to how you launch the entire infrastructure. Second is, so you have the EC2 instances running. What do you want to do in there? That can also be controlled using the user interface. So here, as you can see, the script automatically is installing all of these packages from here. Right? And apart from that, you can also, before you go, suppose you have something that will get repository, you want to copy it into a particular folder in this case, user local name, so it can actually pull that code and deploy it here. For your instance, so if not only automates the entire infrastructure, it customizes the operating system and the server-side environment and deploys with custom code on top of it. So all of these three aspects of automating your infrastructure and application can be covered through this. Now if you recall, the elastic being stopped, so in being stopped, you only focus on the code and let the entire stack be lowered because automatically, whereas in CloudFormation, you can customize the operating system to a certain extent, whereas everything about that is totally customizable by Reduce. So you can define whatever you want to do over that in past. So does that give you an idea of the difference between being stopped in CloudFormation? So I also have a demo for CloudFormation. So this is the CloudFormation portal. As soon as there are multiple templates already available on our web page, you can actually create a WordPress site through which most of the templates are already available. You can select some of the options in there. Since this is launching a database, the database parameters can also be configured here. So when the database comes up, it will automatically have some of these options pre-configured in. This is called tagging. So whatever resources you launch in Amazon can actually be tagged. So this tagging is a powerful feature. It allows you to do cost allocation plays charge maximum. So we'll talk about that. So the status log creation is in progress. Here also you can see all the events which are being launched. For this again, we'll do all of these. What else do we do? We start it in the JSON template. We can all make people getting logged here. As you can see, all the events are logged and we fill in the create country. Half of the people will see the output. So there's something called output tab. You can see the output of that CloudFormation template across the format. So now the entire application has been filled out. Now if you want to terminate all of this, all you need to do is right click on this and say terminate. So this CloudFormation will actually destroy all the resources in the pack. So in this demo, it's creating an image so that you will screw up that. Any questions about this? I hope it gives you an idea of the distinction of the two services. So now let's move on to AppSource. So now the two services that we spoke about being stocked and CloudFormation, we did not talk about how we're going to manage your applications. I think, just we would have touched that in this session as you have, say, hundreds of servers all having a particular version of an application. And now you want to update all of those hundreds of servers with a new application. How will you do that? So that is not explicitly covered both in being stocked and in CloudFormation. However, there are ways of handling that in being stocked. You can have another version of environment and swap the URLs. CloudFormation can create another stack and then swap the URLs. But there is no time to be handling that in the other two services. First, AppSource is actually made to handle that kind of scenario. It is an independent application management solution. So it is dependent upon the so if you are using SHIFT, it can actually take that SHIFT recipes and include that part of this. And it can allow the full control and automation of the application that you are living in. So these are some of the management challenges when you deploy applications and when you are scaling to a very large level you will see that none of the shell scripts or the manual efforts will be able to handle them. So it comes back very reliable. So this is the critical tool that you can test, publish, and monitor. This is just an example. So you can do the coding for the entire development system using Jenkins and once you want to deploy the tool you can push it to OpsWords. This is again an example. So in another environment well this is something that we do not explicitly control in an OpsWords like environment you can have a full control right from the underlying surface environment to OpsWords for this time. This is an app and database that is called a stack. And then you have the layers so web layer, app layer, dba layer so when you throw a server into a particular layer you don't need to think about how it's going to be configured. App source will automatically get a server in a web layer and configure a more improved server definition that you provide. And this is how OpsWords works this is the orange box in the middle that will actually keep on calling the OpsWords service and whenever there is a load release etc. it will do the beta data from OpsWords get the code and some of the beta information from S3 and get the actual code from GitHub deploy what will serve and publish the shelf blocks etc. back to the S3 and acknowledge back to the OpsWords is there is there like a dedicated Chef master server running for each of the stacks or each of the environments or OpsWords service will manage that so that acts as the Chef master so our definition of beta is different beta does not play that it's not production ready and ready for support beta means that we are still not at that feature parity as compared to the RPS beta service has been in beta for a very long time and got out of beta now but we took the support in production from our perspective it wanted to be feature parity with whatever is leading the customer yeah yeah correct but point is that there is no Chef agent that sets in a beat stop if you want to do your own you can do but then it doesn't come bundled as power to beat stop service and so this is as you can say this is heavily dependent upon the agent that sets on the EC2 in beat stop you can launch another version of the application or another and then do the swap URLs etc. but that is bit of a work if you want to customize that you can take the raw AMI that Oxford skills customize that with your own code and then publish it back into Oxford studios there is right now not a straightforward view of doing that but that's possible similar in beat stop beat stop case some AMIs which are built in into beat stop you can take that AMI launch these of Oxford does allow you run your own custom chef recipes that's all about this that's all about this chef so does it give an idea of your first ability services great job so this kind of summarizes the whole thing so you are beat stop Oxford so there is the convenience versus the convenience you just upload the code and forget in Oxford there is a bit of a work but it abstracts again a lot of information you can start from bare minimum and put it up from there and on easy of course you can do whatever you want to do so this is the whole nature of it I am on web services that's focus on your core application and let the entire undefinition obviously that's a thank you very much I think you take any more questions that you may have how do you get into that writing on these these all so these all these services are such a key there is no charge for every of these services what are the resources that get spun up by using those services are charged so there is I'll say I have 10 servers out of those 10 servers 5 servers will be run in 24 cross 7 the other 5 will only count 50% out of the time it will take so you can only estimate there is no guarantee that it will work with your end but depends upon your book yeah billing allows so I think he's talking about the estimated billing in advance before you employ an infrastructure that is difficult but that's the whole value of cloud that you don't I mean you worry about your cost but you can worry about the infrastructure they can they can they can they can they can they can they can it's not going to go down because they have that that. they will be serviced based on what's the curiosits mob because you know that all that There are data rates which you cannot predict. Data rates. Data out. Yeah, data out. Yeah, correct. Yeah, so you can predict the maximum instance. Correct. You can do an individual guess and then, yeah. That's correct. Great. Thank you very much. Thanks a lot. Thanks.


Okay, so on the 20th we saw a new release of basically all KD apps. This includes the last, I don't know, four months of development on any app, so it's a big deal. That said, let's check out what is exactly new. What is new? Exactly, I don't know. Let's start with a spectacle. The entire application was completely redesigned from scratch. Also now has a screen recording out of the box. However, Noah Davis put a tremendous amount of work into it and the application now shines. This is the application itself, which is now in QML and has consistent and pretty header area. The right column has a screenshot and recording section. The screenshot one you already know, but the recording section allows you to select what to record, all screens, one screen or one window, and also what file extension to save in. This is the first big change. The second big change is when you do a screenshot of a screen area. Previously, you'd press enter and go back to the application, but now you see all the screenshot options directly underneath the selected area and you get all the image annotation tools directly exposed there, which makes it so much easier to actually go ahead and add fake mustaches on other YouTubers, something that I do all the time. Dolphin. Finally, you can run Dolphin as root, allowing you to edit system files too. Kind of. The functionality, which is quite dangerous if you don't know how to use it, is actually disabled by default and works through a Dolphin plugin called KioAdmin, which moves the security burden on the KIO framework rather than on Dolphin itself. I know it's not as easy as just typing pseudo Dolphin on the console, but that command does explain to you how to enable the plugin. If you own Apple iOS devices, Dolphin now supports natively navigating its files through the AFC protocol, something that, unluckily, I'm not able to test out, given that I'm legally not allowed to be within 100 meters of any iOS device. Finally enough, the official announcement here says, despite these added features, Dolphin has not become slower. Wow!  Kate and Kewrite. So there is a new code formatting plugin that provides a simple way to format your code. It supports Clang format, Rust FMT, Pretier, Go FMT, Dart FMT and some other formatting backends. It can format untitled in memory as well as saved files. The goal was to provide a smooth, high quality and configurable code formatting experience to the user, whilst keeping the usage really simple. You can either run it manually or set it up so that it runs every time you save. The unified diagnostic view. So basically, instead of every plugin bringing its own UI, there is now a unified component that everybody can use and it's reused by many plugins. This allows to add new linters much more quickly and, in fact, Kate already added support for AES lint using this. Then there is LSP inlay hints, which shows virtual text for, as an example, parameter name at the call site of a function which can enhance code readability. Configuration is also now a dialogue again instead of an editor tab. I guess people prefer the old way. And Kate will now detach from the terminal after launching, allowing the user to use the terminal session for other things. You can still open it in a blocking mode by specifying dash B, as an example, Kate dash B on the command line. KDN Live. So there's also a big new feature in KDN Live called nested timelines. Basically you can select multiple clips in your timeline and group them together in a single clip and then just continue editing as if it was actually a single clip, meaning that you can add apply effects on it, transitions and so on. The whole sequence inside that clip, thus named nested, will update accordingly to all the changes that you make to the grouped clip. You can also later go and edit the nested clips and that change will immediately update to the grouped clip as well. Honestly, KDN Live is shaping up to be an incredible video editor. Allow me to showcase a feature from the last version actually, since it's not very known but it's just so exciting. So there is a third-party application called GluxAnimate, which is meant to make animations, simply enough. That application has a very good relationship with KDN and in fact, the developer has said that they're currently working on joining KD, meaning that KDN might soon have an application to make animations. Okay, in the previous KDN Live update, the ability to open GluxAnimate files was added, meaning that you can create an animation, save it to file and open it in KDN Live without even having to render it. And the coolest part is that if you make any change on the GluxAnimate file, that will update live to the KDN Live view as well. I mean, come on, this is the coolest stuff. I'm so excited. GwennView and Ocular. Okay, so there's only one significant change to GwennView and it's about zoom, which now works much better. On Wayland, you will be able to zoom in and out using the pinch gestures on the touchpad, which is actually a super nice thing to have. And in general, zooming with control scroll on a touchpad will zoom in smoothly instead of doing big steps. So yeah, it's much easier to zoom into images now. The smooth zoom patch was also applied to Ocular, meaning that you can now zoom smoothly instead of going by steps when you do control touchpad scroll. And since we're talking about Ocular, you can also unlock the sidebar and move it around like on the right side of the application, or you can also leave it floating around. They all float down. Elisa. We don't talk enough about Elisa. It's KD's best music player application. If you use it, you know that the application has a giant blurry header that showcases the title of the song, the album art and the author. Here's the cool thing. If you don't like it, you can now just resize it to be a completely normal header area. You won't be able to see the song title or author, but the application actually looks better to me like this. I don't know. I'm just really into good looking header areas. Sorry. Also, you can now create playlists and save them as .pls files. And you can open .pls files. You can now listen to the radio if you were born in the 20th century, I guess. And most popular stations are included by default. Finally, the frequently played view now just sorts by the amount of times you played each song instead of trying to do some more complex heuristic filelight. You know, the application that you run when you notice that you're running out of this space and you would like to know why. Now along a super pretty graph showing the size of the folders and subfolders and sub-subfolders, you also get a left view with a list of your folders and their sizes. This makes it a bit easier to parse all the files in the directory you're in, as the graph does not make that immediately obvious. Now one application that is not in the KDGear update because it's so new, but it will get in the KDGear update. And anyway, it has been published a few days ago, is Arianna, which is KD's new application, super new to read app files, which I'm mentioning it because I created it. It was mostly developed by Car Schwann, thanks Car. And other developers also joined in and gave me a hand, gave Car a hand. But yeah, I did something. And I'm still working on other stuff on KD Plasma Desktop. As an example, currently I'm working on some stuff for eInk devices and also on floating dialogues and also on a redesign of the panel settings thanks to another patch. All of this can only work if I get enough money to make everything work, even the channel actually requires money to run. And about that, I do really want to say thanks to all the patterns which you should see here in the last video, the editor forgot to add them in, but I really want to say thanks for everybody. April is coming to an end. And I'm actually not really close to my 700 euros goal, which starts to give me a little anxiety, but I'm sure, I'm sure we'll get there. If you're able to chip in something, that would be awesome. And thanks to everybody who is helping. Let's get back today. I feel like I'm out of focus. Itinerary. So do you plan to travel anywhere these weeks? KD Itinerary is an application especially meant for phones and available on Android, which allows you to upload your train or plane tickets to get all day info they contain. Some recommendations if you're traveling between states that, as an example, have different power plugs and so on. The application has been redesigned for this release, and it's now much prettier and much easier to navigate through the information such as the QR code of the ticket that you actually have to show at the airport. There are gone player. This is KD's video player application. And although it's not much used, people usually either use VLC or MPV, MPV, and it wasn't very maintained. In the last year or two, it has received a lot of love to make it more appealing to users in the hope to change the status quo. This does apply to this release as well. There has been a major overall of the design and the application now uses KD's hamburger menu, which is KD's powerful hamburger menu. The default set of toolbar buttons was also moved to icon solid, which is the standard for a video player, with the addition of a clear button. And finally, the application now has a welcome screen, which allows you to either play a file or a stream. By the way, the application comes with a sidebar hidden by default, but it's in the hamburger menu that allows you to change brightness, contrast, you and saturation of the video, a very interesting approach. And I guess it could be helpful when playing like very dark movies, changing the brightness. However, it does not work on my computer, so I'm not sure why. Casts. Casts. How do you pronounce the cast? So I know that you might not see this application like cast very often, but there are a lot of these applications that are quite new, actually, and slowly becoming better and better, but also more and more used. Casts is KD's application meant to listen to podcasts. The latest version supports minimizing the application to this instant rate. You can change the playback speeds of your podcasts and you can search with, by the way, a super pretty search bar through your catalogue of sub-s-s-subscribed podcasts. Now, the rest of the things I'll talk about now, I've actually covered just a few days ago. But still, for those who missed that particular video, I feel like I should cover them here as well. Feel free to close the video if you hate repetition. You were warned. Tocodon. Tocodon, KD's client for Mastodon, now shows you previous messages you're replying to when you're drafting your surely hateful response. And there's now support for polls, which you could already see in previous versions, but you can now send them as well. Finally, the mobile version has a dedicated search page, whereas the desktop version always has a search bar on the top left. And finally, you can now configure a proxy before logging into the Mastodon account, which is a step you could take for further security. Finally, you can also review the list of follow requests in order to be able to click on deny on each single request, except if it's from me, obviously. And yes, that's the same joke I did in the last video, too. Oh, YouTube. This is KD's YouTube music client. It has gone through a complete redesign of the interface and also now has new pretty icon. The application supports searching for music, making playlists and creating them automatically from your favorite songs. You have a playback history and you can now share songs with your friends, like if you have any, Neochart. So Neochart is a native KD app for chatting on metrics. Neochart improve its design with tricks that provide a more compact layout and a simpler menu which works better for the collapse room list. There is also improved video controls and a new command. There is a new command KNOC room ID to send a KNOC haven to room and you can now edit a prior message in line with a chat pane. Other usability improvements include a overall of the keyboard navigation and shortcuts like control page up and page down that allow you to skip from room to room. Then there is calendar, which is a modern and highly interactive calendar calendaring and contact management app that works really well on your computer and mobile phone. And there has completely revamped its address book which is now more functional and easier to use. You can see it here and you can also edit contacts and by the way, those contacts are also exposed if you want in the system tree for easier access. Plasma Tube. So Plasma Tube is a video player that allows you to stream YouTube videos directly to your desktop or phone. There has been a redesign here too with the rounded corners in the video preview just like YouTube does. And Plasma Tube now protects your privacy as it accesses videos through in-videos, a YouTube front end that does not require a login blocks tracking and hats and does not require JavaScript. If you do that, it means that I'm not getting any money so stop it, make a donation or something. And finally, there are some smaller changes such as Arc has more options in the welcome screen and you can finally extract Staffit files which I did not learn about whilst reading the non-spent. I totally knew what Staffit files are. Totally. Thanks everybody for following through and see you in a couple of days with me. Bye.


As temperatures cool down this season one church is hoping to warm things up by giving coats to those in need. I had actually seen someone set up the coats one year and I thought well that's such a great idea and nobody was doing it in front of the coffee house. So I called the owner at the time and I was like would you care if we did this and he's like absolutely. By setting up a coat rack the First Christian Church in Paintsville will be assisting those in need by offering coats for free. Outreach coordinators Amber and C.W. Vanhoose say the coat rack is a much needed addition as COVID-19 has made things hard within the community. If somebody needs a coat it doesn't necessarily have to be somebody homeless. We know that there's a lot of need right now especially with COVID and all the sickness that's going around feel free you know that's why that it's there. We're nobody special we're just trying to do something good for the community because this community has given so much to us. Here at Pikeville Medical Center's Heart and Vascular Institute we have assembled a comprehensive team of cardiac specialists bringing expertise from all regions of the nation and the world. We have coupled that with cutting edge technology providing them the best equipment and operating rooms available. The result is comprehensive cardiac care for the people of our region that is second to none. The Heart and Vascular Institute at Pikeville Medical Center. Vanhoose also says that the coat rack is available 24-7 and that they're always accepting donations for a variety of items. There's always coats that are changing so people will drop coats off people will take coats shoes well whatever say that you need something and it's not there come back and look the next day maybe there's not a coat that you're size it's always it's always revolving. We do have a blessing box here at the church and there's several in the area and we do accept canned foods non-perishable goods that or personal items that we can put in our blessing box and for people to walk by it anytime of the day or not and they can take from that box. If you would like to donate you can drop items off at the coat rack located in front of the coffee house in downtown Paintsville. For other items such as food you can call the church at<PHONE_NUMBER>. For Mountain Top News, I'm Joel Korjol.


My name is Kate Stewart and I'm the director here at the Linux Foundation and I'm here to talk to you a little bit about open source and safety critical applications. This is a topic that ties together a lot of the areas of interest that I've been working on for the last few years and hopefully helps put some of this into perspective because open source is already being used in safety critical applications. We just don't have as good a visibility as we'd like and we need to help work on improving this over time. For example, in autonomous vehicles and on cars and systems, we're hearing about it more and more. There's a lot of devices that are being used in there that have uses in other places. Safety as you can sort of see here is being considered by people in the sense of avoiding accidents and avoiding hurting people, which is what we want to do obviously. But there's safety considerations around the electric system. There are safety considerations around the smart signaling, the infrastructure around it. So safety is pretty much everywhere and open source and it is literally in most of these systems and more and more as new people have new ideas, it's getting within open source and therefore we're going to need to figure out how to make sure we have the right level of analysis to make these systems safe going forward. Another example is this recent SpaceX rocket launches. They are very visible in public about having Linux in them already and various subsystems inside these rockets and on the Falcon capsule. So we know that open source is going up there, is going up to space and we want to make sure obviously it's going to be getting there successfully. And then with everything that's been happening in the world right now, since the start of March there's a group that has started looking for open source solution for ventilators for low cost implementations for dealing with the lack of supply. It started off that way but also in low cost areas that don't have a lot of resources and so forth. We wanted to make sure there were solutions available and all of these are open source ventilator systems. And so people want to help and open source is a way that they can look towards trying to help. Now the big challenge is making sure that what they're doing is being used in safe and effective fashion. Not only is it open but it's buildable, it can be support, it's been functionally tested for the safety, it's been rodably tested and so forth. And so this spreadsheet which I've got the link to here will give you what the latest update is from this group that's working on that. And so people want to be helpful, they want to be creative, open source gives everyone a way to participate. And so the challenge is now how do we make sure we become a safe for use. 99% of code bases actually are open source, at least that's what BlackDeck found when they did their survey last year. And of those code bases over 70% of the audit code was open source code in there. So it's there, it's pervasive. Even if it's not advertised as such, it is present. And all this new functionality, Sonatite's report also says, you know, indicated they've been seeing like, you know, double and triple digit growth for these components and these components are what is making up the functionality that's getting so excited for people, but they're not seeing a slowdown site. So open source is here with us and our challenge is going to be how can we make it effective and safe. This is particularly challenging in that most of the modern digital infrastructure you know, aren't able to accurately summarize the software that's running on their systems. They've gotten a container from someone, it does a job they need to do, they put it in, et cetera. Well, we can't have that type of environment in safety. You need to know all the pieces because one of them could be vulnerable, it could have a, you know, a security bug, it could have a regular bug, it could have a hazard, a timing hazard. We need to know all the pieces to make sure a system is safe and we need to have the full traceability and accountability of the provenance behind them. So getting all of these people, all of this information pulled together is not something that we're used to seeing a lot of in open source. Having that detailed understanding of all these elements is key if we want to be able to do the right level of analysis to have the safety claims and make sure that we understand that systems we're putting out there are safe. A lot of the safety standards have been evolved over the last 30 to 40 years and there's a wide range of them out there and they have different considerations but at the heart they're all looking to try to figure out how to minimize and mitigate systematic faults. So they're looking at, they're looking at things from a system perspective and that's the key. Open sources are projects but the products are being used in systems. So we need to figure out how we can get accurate summary of all the information there and then be able to have the right level of evidence that it's known, it's tested and it's managed. So that's what these standards are looking for which is not, you know, an unreasonable goal. The challenge now is how do we map that and work with that with these open source projects? So closing that gap is going to be key and the first step obviously is to improve the software transparency. We need to be able to very quickly and accurately know what software is being used in a standardized software bill of materials. So if you've got your system you need to be able to, you know, how about your fingertips without having to go and ask someone, be able to serve well, you know, or even worse than going and asking someone going and doing a lot of forensic, you know, digging and checking out that what's in that container that you're running this application on that's doing this and this and this. So we can't do that in a safety critical system. We need to have, you know, accurate information that needs to be summarized and needs to be available. We need to know what latest versions are running and how the components interact with each other. And software bill of materials at least lets us start to do that. Software bill of materials is a formal record, contain the details of supply chain relationships of various components used in building these software. These components include libraries, modules, and they can be open source and they can be proprietary. They can be free or paid for and the data can be wildly available or access restricted. It's not really prescriptive here. Anything that makes up a system we need to be able to articulate in the bill of materials. We've got this discipline in the you know, in manufacturing and hardware. For that matter, effectively it's the ingredient list not serial walks. This information is sort of key and there's been an initiative from NTIA in the U.S. and I think they've been working with the JPSert folk to be able to clarify what is in the software bill of materials and how we can take and make it more effective going forward. And what's the minimum viable? You know, that's what everything we want to capture, but what is the minimum we need to capture? So any organization concerned about bear supporting their software products internally as well as their customers should have a less bomb whether or not it's safe to critical. But it is for the safety critical space pretty much a prerequisite. However, if you're not working out, if you're working on application, you don't need to care about safety critical aspects of it. You want your bugs to be fixed. You want your vulnerabilities to be addressed. So you're going to need an S-bomb for those reasons. Some cases it's contractual. It's part of the negotiated terms with the supplier like a tier one and tier two. You know, there's some supplier relationships that you've got to provide one. In other cases, you'll want to have an S-bomb to comply with the legal obligations of the open source and any regulatory obligations. And then from the technical perspective, this is where, you know, you want to know what your supply chain risk is like. You want to know what your vulnerabilities might be. Are you are using writing a component that has a vulnerability potential? And then in the case here, we're caring about is safety analysis, you know, you need to know what's there to understand whether or not it's safe. And so as well as you might be using it as well internally or system for asset management too. So an S-bomb should be sort of used effectively. And there's a group, you know, working, there's several groups working as part of sort of a stakeholder, multi-stakeholder process in NTIA. They're trying to defy these things and input from anyone in the world is welcome. It is not specifically, we, you know, it's not specifically to one country or anything else. It's literally, this group is trying to help figure out what minimum viable is and make sure it's effective for the industry. And when can you use a software build material as well? You can pretty much use it anywhere in the life cycle. You may have reasons to, you know, when you're developing it, you want to make sure you're getting the software as specified that's been built. You may want to make sure after you've tested it, you know, the results are there, other certifications are made visible or unavailable. When you release it, you know, obviously you're passing it down your supply chain to whoever you're releasing it to. So it's a lot of information you may want to keep. And that's usually the trick, you know, the typical point where this software build materials is kept. But, you know, going forward, looking at this, you know, bugs can come in, you may want to keep that and track that with the software. Oh, there's been an update. You may want to have references to that. Pretty much anywhere in this life cycle for a software, you're going to you may potentially want to have an S software build material. So we need to figure out how we can generate it effectively and efficiently. You know, why care? I guess I've said it for us already, but securities are prerequisite here. We need to know what's theirs to make sure it's secure. And we're seeing a lot of interest emerging right now on the cybersecurity supply chain management. So this is helping motivate awareness across the industry. And, you know, people want to reuse open source, that's the heart of it. And fast time to mark is achieved by reuse containers that make it very easy to deploy things into your system. But what's under in those containers is not always obvious. So software transparency has got to be there for us to do the analysis for safety, but it may not be machine readable. And so you may know from us spreadsheet here and something there, but we need to get this stuff automated and visible and available. And we're seeing a growing awareness now with the regulatory authorities from the cybersecurity threat, but this is also going to help the safety space. So the FDA and FERC, Federal Entry Reserve, they are the ones that are starting to sort of say, hey, no, we need to have this software transparency in place. And, you know, some of the things that we're sort of starting to see is directives emerging. Some are not making directives yet, but have signaled they will. And basically these are under, you know, have an implicit assumption that there is going to be some sort of the transparency is going to be in place and maybe a software build materials, but that transparency has to be available. So how are we going to do this? Well, at the Lakes Foundation, we've got some birth projects that are working towards helping this. Obviously there's Open Chain, which is documenting the processes and the norms for sharing software build material information. And then we have a common format that we're using for exchanging the software build material information. We've taken this from the work we've been doing out of open source licensing and we're extending it to handle these other use cases. And if you've got a format and you've got norms, well, that's great, but kind of need tools too.  So if we go into the Open Chain specification, which is now an ISO standard, you'll see, you know, section three. There's the expectation that there will be a bill of materials for each open source component that's being used from which the applied software is comprised. So there is that expectation right here at the heart of this in the processes that it's going to be an SBOM. To facilitate this accurate tracking through the supply chain, you know, being an upstream or supplier, you're going to need to be able to say exactly what you're brought in.  Or if you're, you may want to make sure it's accurate and you may want to feed it back into some upstream open source projects too. So accurate tracking is going to be needed pretty much throughout this to have that feeling understanding of the provenance. And more than the provenance of how we get this information through the supply chain, it's also the pedigree of how we're building things. What are we pulling together, or the config options? Reproducibility of the builds and remaking the products. If you can do that, you really know, you know everything that's in there. And the pedigree and having that information is going to be key for a lot of the safety standards as well. So this information is sort of coming together and sort of saying, hey, we've got to start tracking this, we've got to start working on it. And so this is one of the reasons we actually updated the SPDX mission this year, to expand beyond licensing to actually save provenance and licensing and security and other related information, like the pedigree information, how things built. And then, you know, what the usage information is and that's something that I know that some of the Open Chain Japan working group want to start capturing. So we're extending SPDX beyond its original licensing to also enter the security as well as the provenance type of information and pedigree and so forth. So we can actually track what is needed for the safety analysis. And to make it easier for the tooling, the automated tooling workgroup umbrella has formed with there's a variety of open source projects that are agreeing to exchange information with these SPDX documents. And some of them are being done during the build. Some of them are done as inspection after something's created like Tern, which just lets you look inside containers and physiology, which lets you take in, you know, a package and then help you understand what the licensing is and generate out an SBOM document. And then there's also there's also tools from the SPDX project which help other tools as well as let you consume and transform what's happening in this ecosystem. So that's sort of a little bit about, okay, we're going to work on the software transparency piece. Well, what about the actual functional safety? I think the key for functional safety that we're starting to emerge is we really need to understand the interfaces, the quality levels, and the safety characteristics of these open source projects. Because as people pull these building blocks together, they need to understand how they're fitting together and what they need to pay attention to. So right now, we're looking at how we can sort of move this forward. And there are projects now at the Linux Foundation that are considering functional safety. We have the smaller footprints like Zephyr and Cell4. We also have hypervisors like Acorn and Zen. And then we have Automotive Linux. You know, all those automotive use cases are right at the heart of this. And from there, there's also the Alisa project which is trying to look at Linux as a component on its own. And these are larger footprint type of things. So we have a fairly wide spectrum in the ecosystem that we're going to have to look at. And how we can move our way there is going to be key. So let's first look at Alisa. We're looking sort of both ends of the spectrum here. And at least it's just Linux. And what we're trying to figure out is how we can use Linux in these safety critical applications. I don't think it's any surprise to anyone in this room that Linux has grown to be one of the most important open source projects in the world. Last year, over 69% of the embedded systems market was using Linux. And that embedded systems market is where we're going to be finding these safety critical applications. So it's already like say it's there. And what we need to do is figuring out how do we make Linux safe. So since it's so pervasive, there's a group that's formed around trying to work on this problem together. At the heart of it, to assess if a system is safe, you have to understand it. See earlier comments about transparency. That's one aspect. But if your system safety is going to depend on having a Linux running on it, you need to understand how Linux is being used in your systems context. Again, it's the system that the argumentation for safety is being made at. Linux is a component in it. And what we need to do is help people understand the pieces they need to pay attention to. And accurately summarize it so that they're not trying to, everyone's not trying to reinvent the whole thing by themselves each time. So as we said, I can't stress it strongly enough. The difference between Linux development for safety critical and a general application is just how are you using it? You need to understand your system, understand the Linux interactions. And then make sure your system is using Linux based on selected properties, where you want to ensure the quality exists. If you're not using a driver or if you're not using some sort of feature of Linux, it doesn't participate in the safety argumentation. How it's configured and what you're using is what you have to focus on. And so Linux has a lot of the things that the safety standards are looking for. Okay. The fact that it has been in continuous development for over 29 years says a lot in a lot of people's minds. And that it's used so widely means that there's been a lot of testing that's been going on and a lot of debugging, a lot of bug fixing. There is a continuous improvement process in place when they're rare. When they develop, when issues develop over time, it's continually being improved. The maintainers get together once a year and they have mail lists for discussing these topics and how to improve the systemic side of things. So by that definition, it's sort of there. There is evidence out there already for the quality, for the process quality and process improvement quality. These are things that the standards are calling for. And the evidence from some of the analysis that's been done by some people who've had more experience in the safety standards than I do says that the safety integrity level two for selected parts and properties have probably met. Now the challenge is, okay, how do we convey that to those people who are doing the safety analysis in a way that we have coherence? So Lisa's trying to tackle this and the mission statement for Lisa is to define and maintain a common set of elements, processes and tools that can be incorporated into specific Linux-based safety critical systems and make them amenable to safety certification. That is what we're trying to do with the Lisa project. And closing those gaps between the criminal development community or any open source community for that matter and what the safety standards are sort of saying, they're talking two different languages and we need to figure out how we can reach together and convey concepts in the terms each other understands. So we've got two groups inside of Lisa. There's more than that, but these two groups in particular are worth understanding how they've worked. The criminal development process working group is trying to take and look at what the safety standards are asking for and then identify the evidence that's in Linux and carry collateral that illustrates what's there and how that is addressing the gap or finding out what the safety standards are looking for or else identifying a gap that people can work towards filling. Now, the safety architecture and working group is also looking at this problem, but it's looking at the problem from the inside of the interfaces and the functionality inside Linux. And so what's being, how do pieces of Linux work and then what is the common summary of the information from there so that that can be then used in further analysis? So these two pieces together are helping to sort of build up a layer of bridges here. And eventually we should be able to build the gap. Now, as I've said before, Linux needs to be looked at from a safety context, like from a system context. And so we need to figure out how we can prove the path. So there's two working groups that have already spun up in the last year in the Elisa project, one of which is the Medical Devices Working Group. And this group is busy looking at the OpenAPS reference system as well as we start looking at the open source ventilators initially. And what we're trying to do here is look at using STPR, System Theoretic Process Analysis, to take and successively refine down the system until we get to Linux. And then when we get to that Linux, we know which interfaces are being called from the system around it, which we have to pay attention to. At that point, we're going to be turning this information over to that current, so the system, the safety architecture group to go in and help us understand the characteristics there, such that we can get a full picture. And we're working, the OpenAPS project is an artificial pancreas system and everything has been done in the open. And it's a volunteer effort with obvious involved. So we're able to look at all the code. It's based on a Raspbian distro, so it's got Linux in it. But we can look at all the code and we can also do the analysis at the system level down to those pieces that we need to see for Linux. Another working group that we've got on this is the Automotive Working Group. And they're looking at a telltale monitor application. And they're basically looking at figuring out, okay, what parts of the system are important and breaking it down as well. We'd like to spin up other working groups. In particular, I think the Industrial Robotics type of group, but we'd love to find people who want to collaborate on analyzing some of these projects that are open. The key though is they have to not be under NDA. We need everything to be open so that we can do the right level of analysis and we can share our results with others. And so if you've got applications that you're interested in that have a safety element associated with them and the code is available up in open source, feel free to come and reach out and see if we can find others that want to work together to do the right level of analysis and help work with the system. Now, with this project, it is very important to understand the limits. With Elyssa, our collaboration cannot make a system safe, okay? We do want to make sure that as we come up with these processes and methods that, you know, you can apply them and make your own documentation. We're not creating out of the Treaty Linux kernel for safety crew of applications. There is continuous improvement. We want you to pick up those security updates. We don't want you to sort of freeze on something because bugs are going to happen. There's actually about nine changes per hour right now in the Linux kernel for new features and there's one change per hour for bug fixes and backwards. So it is continuously improving and, you know, in some sense is the most secure and accurate is the latest. But we want to make sure that, you know, we have systems in place as to when they're deployed, they're safe. And there's a certain amount of things that we can do upstream, but at the heart of it, it's going to be the person who's making the product and making the system that they're claiming to be safe is going to have to own the responsibility and legal obligations and liabilities. So we're going to provide you a path forward in this project and people to collaborate with on the analysis and hopefully work on getting things upstreamed and healthier for everyone because everyone wants to fix bugs. But it is not like, oh, it's all done. It's a journey here. And so once we're finished, we should hopefully have various assets in place for the processes and so, you know, have ideas for which kernels and features and some assessments for you to look at to see how people have done it. We can show it set feasible for certain reference systems and it is usable by people who are doing the integration.  You're going to want to use it for 20, well, 10 at least anyhow. So we've got to figure out how we can get these systems and get them to be safe and safe over time. And we want to make sure that, you know, the standards organizations and the safety community certification authorities understand what we've done and have helped us participate in defining it in a way that they'll recognize it and agree that it's matching the goals. Obviously, we want to help improve Linux too. It's been in 29 years of improvement and we want to see it continue to improve for the years to come. And obviously, you know, key collateral being supported by various hardware vendors is important to us as well. So if you'd like more information about Lisa, I'd encourage you in January we're going to be having our next virtual workshop end of January start of February. We're still setting with date and in those workshops, we sort of go through different topics and you can deep dive into the area. And then there's weekly calls that are going on right now. And there's a monthly TSC call. We haven't felt full open mail list. Anyone is welcome to join. And we have some projects we're working on up on GitHub. And so encourage you to go explore and then reach out if you've got questions. Now, switching from Linux to the other end of the spectrum, we've got Zephyr. And Zephyr is another OS and it's meant to be used where places where the Linux is just going to be too big. And there's a lot like on the sensors, on the actuators. And we're going to need to have the same sorts of properties we've got Linux happening in Zephyr. For those who don't know Zephyr, it's an open source real-time operating system. We started the project in 2016 and we knew we wanted to go after safety and security goals because that's what was missing. We had this point now have a vibrant community associated with the project. There's over 800 developers that have been active in the community and there's over 100 usually active each month. And so in terms of the participations, we're looking sort of like I think Linux is nine changes per hour. Zephyr's Bible change an hour. So we're getting 800 plus commits every month type of deal. It is licensed differently than the Linux curl. It's under an Apache 2 license. However, it has a vendor neutral governance in play. It's a technical committee, you know, the technical steering committee is what makes the decisions about the technical content of the code. And it's very modular. There's a lot of things that are similar to Linux that it's using the Kconfig. For instance, it's using device tree. So people who are used to embedded Linux developers tend to find it a pretty comfortable environment to work with. And we're using it also is using something like the it's using the long term support mechanisms that Linux has where every two years in this case, not every year, but every two years, they cut a long term support kernel. And then security fixes are added back into that as well as and bug fixes. So we have that type of that was the lesson we've learned from Linux and we're continuing going with Zephyr. At this point now the architecture as you can see is fairly complete. It's modular. So you only compile what you need, which is what we need for this, you know, very tight footprints. And it has a very good Bluetooth low energy stack and both the host and controller as well as mesh. It's got open thread. It has a wide range now of communication technologies happening. So you can use it to link in the IoT space, which is what you'd want as well as a variety of interfaces into the hardware. This product is out there now running Zephyr. And we're seeing it recently used for things like the Centrius from their technologies for monitoring the COVID distance and so forth. And we can see it in wearables right now, as well as other applications you see here, but you can sort of see we're heading towards wearables and smaller devices with this. And this is why making sure we have, you know, we have effective argumentation and effective analysis and infrastructure for safety is something that the project cares about a lot. So, right, last year we actually started our safety committee off the COVID base was deemed mature enough at that point. We're initially targeting after SIL 3 level. And we've already established coding guidelines. The initial target actually started in 61508. And that is, as you saw from earlier slides, it served like a base understanding for a bunch of other standards. And so that was deemed to be the target from the governing board. So that's what we're working towards with this project. And we've got multiple activities going on to do more of the traceability and requirements formalization, as well as test coverage and tooling. So we're sort of tackling this one in a more of a traditional sense that's more familiar to the safety standards. And we're already starting to engage with the certification authorities. Quality is obviously going to be a mandatory expectation here.  And we have a variety of other mechanisms in place that we have want to be, you know, making sure that the code is at a high quality before it gets committed to the repo. And if there's a bug, it gets, you know, regressed out immediately. So with 800 commits plus a month, okay, how do we actually get towards a state where we can actually get the right level analysis for safety? Well, this diagram was initially created in 2015. So over five years now. And then when we launched in 2016, we used it. The idea is that the development is happening here. And this is where 800s a month are, 800 commits a month are actually happening, a committed hour. And then every two years, we cut this long-term stable. Now a subset of that long-term stable is what we're going to call auditable. And this is for, we want, we serve expecting people to use mostly the LTS for products. Some may want to use the earlier development. That's completely good. It's just whatever you need for your product. But the products may need to be certified. We want to, you know, make sure that we've got all the analysis in place for that subset. And so in this way, we can keep that community dynamic going here, new features, new functionality, but we can basically have the scope restricted enough that we can go after the audits. Now we're taking this off of our next LTS. And that's slated for 2021. And the actual processes we're using, we're working in the safety and security committees and coordinating with the technical steering committee to make sure it can be applied across the wider base. We are going to be following the V model analysis in this project. And so we're working what the requirements are. In some cases, we're reverse engineering and documenting things that aren't there. And then, you know, working through the architectures for our system, as well as making sure we have evidence and traceability testing.    So we've got visibility into this code. And our goal is to be able to provide the evidence that we can use to map between what's happening open source, what's happening in the requirements and that they've been tested and shown to be working.  Some of the subsets in scope, we'll be starting off with x86 and arm, and we'll be, you know, extending scope over time. I know there's a design of the POSIX APIs, for instance, added here that may show up in the next scope and some of the crypto as well. So, you know, as people are interested in working and we're, you know, building up this evidence space, that's kind of what we're, you know, that's how we're approaching it here. And so we've already started having, this year we implemented project wide coding guidelines to make it easier for us. There's some tooling and processes for traceability that's going to be deployed soon in this next release. And the safety scope functional requirements are going to be starting to be documented as the tools. So we're working a much more traditional path with coming up with the evidence that's being looked for in some of these existing standards. Now, if you'd like to learn more about Zephyr, by all means, please check us out on the website. There's also a Zephyr project website and a variety of orientation. So if you go to the Zephyr project, it's there, but if you want to know how to contribute or the guidelines, you can read up more. We have a very extensive collection of documentation in this project already and it's just building up further. If you want to follow and lurk this email list, you can subscribe to and we have a Slack channel that's very active. And that sort of gives you a feel for what we're doing with Zephyr. So in summary, to get us towards safety and being able to use open source and safety, we're going to have to have that accurate software transparency. These components are going to need to be, you know, tracked and we're going to have to get that all automated. So it's just like in the background, we're not thinking about it. It's just happening. We're going to be moving our way there bit by bit by reaching some of the first projects I talked to. And then we're recognizing that functional safety standards need to and they can coexist, but we have to become efficient at scale. So by these projects tackling this, we're hopefully setting some paths for others. And we're also working with the certification authorities as well as developers to help shape the knowledge here. And the key being, you know, we've got to understand the system that you're using and you understand the components. And then we have to focus on our interfaces and making sure we are able to have the right argumentation for matching the requirements we depend on. And of course, quality is going to need to be there in these projects right from the start. So with that, I'll say thank you very much for your attendance. And if you're interested in these projects, I encourage you to check them out or feel free to reach out to me and I will be available in the chat for more questions. So thank you very much and have a good day.


Hey everybody, so what do you do if you're reaching with your arms in the deadlift? This is kind of a way that I like to look at it, but the problem here is not really an arm problem. It's that your base is collapsing. So what it looks like is when you're deadlifting people will start to reach through the weight to kind of initiate this deadlift and then you're left with this extra-rounded back position. So instead of doing that incorrectly, some ways that I might fix it. Let's say I might even crank your back really, really straight. I might tell you to make sure your shoulder blades are closer together or make sure they don't collapse down as you're going down and I'll just say set that back and then do your deadlift. And oftentimes what this is doing is it's almost overcorrecting and people start to arch a little too much, but at least you don't have the problem that you came in with, right? So if you're reaching with your arms, I want to say set your shoulders back a little bit more and try to maintain that throughout your entire deadlift, okay? And if that does create other problems, just watch some of the other videos that I've made and try to fix those then.