 and I love the talk. Well, that's time of the story with Jogto. So today I want to talk a little bit about Jogto, maybe a little bit about the motivation of the talk of this talk. In the last year we had the first automotive booth. I don't know if it's the first automotive booth ever, but rather it's automotive again and getting going to focus. And in that area we are talking lots of times about Jogto and how to make Jogto user easier with KDE applications and also maybe a good idea to explain what Jogto is. It's in my opinion really hard to get from the internet what it is, how to use it and what it's for. So a little bit about me. My nickname is Cola on the IOC. You can find me in several channels. I'm around for some time. I did a PhD with the Gates theory. That time I was mostly active in KDE and then started at an agriculture company who's doing big tractors and harvesters and forage harvesters and to implement for them. And mostly of my most Jogto knowledge is coming from that time where I'm working professionally with Jogto. And I will tell you in a second what Jogto means. So typical things I'm placed in my work environment are Jogto build systems. I'm using the large Q2C++ and going deep into the available Linux. So really getting something work on an interesting hardware. And a lot of people, some devices that we are having on our desks. What I plan for this talk is to give you really a short overview about Jogto to understand what are the main tools in Jogto, how it can be used and to give you a starting point if you want to take the bump. The reason why I'm not trying to do any other flight coding and giving you examples that typical Jogto training takes about four to five days. It's a really, really steep learning curve when you are starting with that system. But at the end, you know what you are doing but it's complex stuff you are facing. Okay, I want to start with some basic notions and things that we often simply use and I want to explain what it is. There's an artifact picture I have found on the internet and I only took this month since there are some, well, names of the interface on it. So I don't even know that hardware and they're really good. So we're talking about ECUs that are embedded controllers. So essentially, it's a computer you are putting in some box and then you are putting it into your machine or maybe it can also run a cell phone. So it's a specific device that is often really customized for the use case you want to use it for. For example, if you have an automotive control unit in a car or a tractor or so on, you want to have certain connectivities like you want to have cannon bus access. So cannon bus is the main communication system on vehicles. You probably also want to have Ethernet. Wherever we are not talking about the 100 base TX Ethernet you are knowing from your laptop, it's a more 100 base T1 which is an automotive grade Ethernet which differs a little bit on the physical layer. You want to have serial connections since a lot of, well, all ECUs only have serial connections and you're facing this legacy hardware in the system that you somehow have to connect. You have NAND memories that you directly access without some controller like you have with your SD card. And a lot more things. You have on a custom hardware and that is a really important point. We are talking about a custom hardware that is often designed for the use case where you want to use it. And so you have hardware developing that's developed during your software development. And hardware development takes a lot of time. I never thought it'd be less than a year. Hopefully it's less than two years. And at the beginning you have a few protocols. Maybe one, two, or three that you can use. Later on maybe 10, then 50, then 100. Depends on how good the, or how finished the hardware is at that time. That also means for your development that often you have only really few devices that you can use to test your software. And that's a real problem since you are developing software that must run very efficiently on a built device, but you don't have it. Or you only have one or two to test in purposes. So the hardware really evolves and possibly also the hardware part inside the entire device changes over time. You also might have a custom question process or that's really often. Like you're only doing system updates where you're from somewhere allowing the whole root file system and updating it. Or you have another custom system where you want to update it. So it's not like a typical line system where you update the packages one after each other. At least often it's not that way. Usually you have different hardware you are developing on than the hardware you're developing for. So it's you often as an device. And I think most of us don't have an ARM device for your main development. So you're creating a software on x86 device and building it for an ARM device. And so you're also faced with a problem that you have cost building to change. So building one architecture for another architecture. And well in this talk I'm only talking about Linux operating systems and I'm not talking about real time. The issue, I want to talk about this talk or the issue statement a doctor twice to solve is the following. Let's assume we have a specific review. We want to develop software for. That means we want to have a full system image that we can flash after work on the image. So maybe at the end of the line where you are really in production or your system image that you update later on. The system image shall contain the implications as libraries that you want to flash. And it's important that no magic happens. So that it's really a rapid use of the build. You can start it again and again and again until you get all the same results. Hopefully without getting arbitrary sources from the internet. And it must be also very fine. If you maybe get some revenue years after from the trip it's also possible there. And we are working on x86 machine. And this talks about how you have to try this on it. And I'm still not really getting to the techniques but I'm getting more to what you have to is. You have to isn't really a tool. You have to is an organization project that uses several tools. I have found this really nice approach from the doctor project. The project is an open source collaboration project that provides templates, tools and methods to help you create custom language-based systems from valid IoT products regardless of the architecture. So that is what they want to do. And they are gathering tools from several areas and creating an ecosystem where this is made simple. Since years before we were faced with arbitrary build systems from your hardware vendor where you are stuck with one specific vendor and a build system, and you could simply change to another one. And that's also, well, also an open source, we really don't like that. So the update project tries to make an ecosystem or make new life-pricing simple to provide all the tools that you need for doing the job for creating such image and to reuse what you did. A few basic notions that are extremely important to your career are the following four. A recipe is maybe the most fundamental elements of your career. It's like a recipe for cooking sauce bolognese. You have a few ingredients that you need and you have steps you have to do. And at the end you get to the side. So these are recipes for making software from how to get the source code, how to modify it, how to build it, how to get the result, and how to package it. A layer in the Yachter sense is a group of recipes. So several recipes that are shipped together. But there's a little bit more. It's not only the group, it's, well, the name probably names it. We have layers on top of each other. And that's one of the biggest strengths of the Yachter system, that has these group of recipes that has taken each other. And that also means that a higher priority layer can adapt large priority layers. For example, if you have a big recipe for a certain library that is not working for certain architecture you are working on, then you can add a patch to a higher priority layer to append the recipe and modify it in a very fine way. And getting, well, you have adaptations in it. Or maybe you are a specific patch, as you did. Then the image. I'm talking always about the root file system image. So if you're going to a Linux PC and doing NS at root, that's what I'm doing. And then I want to have one big file that I can put onto my very device. And we're talking about SDKs that have specific slides. So, what's a little bit confusing about Yachter is that Yachter uses a lot of open embedded software or that information is distributed between Yachter and open embedded on the internet. And the reason is that it's not shorter. Open embedded came from guys who made systems that run on power computers. And I looked a lot into the cost-paying process and the tooling, and they did a really good job. And they are really good results that are simply reused in the Yachter project. And there are two crucial things that I will show you in the next slide. One is open embedded core and one is BitBake. BitBake is the building tooling. Open embedded core is the meta data you need for building. So, in a nutshell, what open embedded core is, it defines the crucial bits for your cost-combination. So, it defines how essential tasks are performed, like how to obtain source code. And that's as simple as it sounds. It's different when you are getting source code from Git, from SVN, from a table. There are several ways how to obtain source code. So, their task defines how to configure source code, for example, a CMake, how to set up big dependencies, how to define what is required before it can build a certain part of software. And, of course, the whole compilation process, how to trigger CMake, how to trigger QMake, how to trigger Autotools. And that's extremely complicated to get everything of the typical tools working. Also, how to calculate the system, which is the target system, but put onto your x86 system in one subfolder that you can use to temporarily store everything you need to build for your target. And also, quotation checks. Moreover, it brings you a lot of these recipes I talked about. So, for the essential things, like you need a GCC, for example, to build something. So, you need a recipe for that. That's crucial. You must build the libc, otherwise, how can the system work? Debas, and there are a lot of things you often want to use, and these are also already provided with open-built core. And they provide already seven platforms. So, you can go to R, MIPS, PowerPC, of course, x86, and which is really important to chemo. So, you have already an emulator that is supported for which, which is an architecture for which you can build and test your software. Secondly, with BitBag. BitBag is a very complex bit, bit system that takes all the layers and recipes and creates your image. It does it by, well, you are defining a list of, you define which layers you want to use. It passes all of them. It also looks at the higher priority layers and it paints recipes from lower priority layers, gets a set of final recipes that you are getting by this layered technique, and then it has all the possible tasks. And then it looks what you want to do, and probably you have built the core image for my device. And then you have some libraries, the applications you find there, and BitBag goes to the tree back and looks what is required to get this image done. And all these tasks are then scheduled in BitBag and run one after each other. So, for example, if you want to build a K archive, of course, you must build a cute core before. And you must first download the source code before computing. So they are simple tasks, and it's not that complicated to schedule it in a naive way, but it's a lot of work to do by BitBag and it takes hours, real hours. I have projects that have from four to seven thousand packages that must be built, and it's about 50 gigabytes and four or five hours on my eight core 32 gigabit machine, since you are building everything from scratch. That's not nice for the developer, but really important here. Then, well, now we have the build tool, we have the core definition, third thing that's, of course, missing the distribution. So how to put everything together? And there are several ways. For example, there's Pokey, that is something that is directly provided by the OptaProject, so reference distribution, how to, well, yeah, power, it's a whole system, target system should look like. You can use it as a blueprint to create your own distribution. You can, well, adapt it, you can also use other ones. For example, the automotive grid line is, the Oaks team can tell you a lot about, there's also an alternative. But these are the three things that are provided by OptaProject. So it's a set of tools, set of definitions, and a way how to create an image. And the power of the Opta system is that a lot of big companies support it and also support their layers, or the layers that are needed. For example, you get a Texas Instruments layer, you get NTP layers, you get all the hardware adaptations from the big companies. You don't have to do it since we have a set of, we have a common language how to define it. The quality may vary, but it's there. The last point for the basics, SDKs, an extremely important point is that's a really strength, strength of your October that you can automatically generate a software development kit with your definition. The software development kit contains everything to start a cross-building. So that's something you can install, like the NDK, your SDK, if you're, the Android SDK, if you're familiar with Android. And then you can get an arbitrary developer that the developer can use it and create software, cross-compile for the target device. That's useful if you don't want to give your hands of area developer to create its own system. It's also useful if you want to share responsibilities. It's also useful in commercial context if you really don't want this close of your source code. And what's also extremely nice is that if you have a standardized range how to create a software development kit, you can use that to set up the build to me. At work, we are using Waze to configure, to create automatically for, we get an arbitrary October SDK and we set it up by script. I bet you can get the same SDK developer to also get the same experience. Which is really nice since you're having, you only have another target where you build from, you run it and on your target the software runs, which is nice. A typical Yachter system, since I talked a lot about it, could look like this. So we have a set of layers, the boxes here. So we have Pokey as a distribution, Pokey already contains open embedded core, it's all the meter information, it's the basic definitions of our tasks, are supposed to be run, it contains big, big, and on top of that you can add other layers. For example, you will probably need the speed layer, so a water product package layer from the hardware vendor, also the device you're developing for. For example, the metered TI from Texas Instruments, or the Metered FSL, or there are other ways, depending on the board you're working for. Then you have for sure a custom layer where you configure everything together, what you want to have in your final system. So what shall we install onto your image? So the libraries and applications and the system descripts for, or system deservices for starting up your system and so on, everything configured and that's a good practice to put it in a separate layer. And then you can extend it with other functionality. There's, for example, the MetaQt5 layer, if you want to have Qt, I guess you won't. And I guess you also want to have MetaKt5, provides you all the most recent KDE framework five layers. And if you want to have Plasma running on it, you can use MetaKtE. So you have a set of different layers that you put together and tell your Qt2, I want to have this result, your part of the recipes, create the build tree, there's everything, and provides you the system image that you can flash at the end, at the board. And well, that's what I already talked about for the last slide. Well, if you have been a talker's talk this afternoon, we now have a really recent set of the MetaQt5 recipes that are updated every release of KDE framework five, where you have updated recipes to build. So the nice thing is for an integrator or developer for a target device, you only have to say, I don't know the MetaKt5 repository, I add one line to my configuration, and I add one line since I want to have KL, and then everything is done automatically. And it's extremely simple to integrate. And that's the real power of the system. I'm not that familiar with the Plasma desktop, but I think Plasma Mobile is mostly completely running, it's a shell, but no applications yet. So if you're ready to add applications, most importantly, the QtGunny applications to make it really nice, but that's a really good showcase if you want to show that your device is working with payment, and all the nice things are working. It's not, but the rendering is okay, which is most of the times the most critical part. So that was a really great, well, long trip about what is Yocto and how to use Yocto, or how Yocto can be used, but I really didn't go into it how you really could start. And that's what some years ago also a lot of time for me to go to the internet and see, well, Yocto, how do I start? And I tried to get a small starting procedure how it might be a good idea to start with Yocto. First of all, there's a really good trick start guys. I put the link at the slide, and you already saw at the beginning there as a component website. That's a nice way to download a few sources, configure a bit big, run it, wait some hours, then you have a result and you can put it into an emulator and see if it works. And that's the first important step to get it building. So you know somehow it's working. The second really important step, and it's always the important step in a very developing development is to bring it onto the target hardware. So at that time, always strange things will happen. It's always the same. Often you will see nothing, a black screen, no network connection you are working, and you have to connect with USB to a serial adapter to get your TTY0 somehow accessed and see what the current output messages are at the beginning to really understand what is going on. But that is, in my opinion, the second step. First get Yocto running in emulator, then go to the target hardware, and best use some where there are already broken distributions like Raspberry Pi, for example. Beagle bone, you can go directly to the motor and use an IMX6, there are also broken distributions. Wherever you have other shortcomings there. And then you can really start playing around with it, and that's use metaxute file and create a small QMA application, running full screen, maybe starting already equivalent compositor and putting some indoors in it, and it's looking cool. It's really, really cool feeling the first time you see a picture on your device. And then beta KDE, put everything together and while you have your first integrated device. The whole problem is it's a really steep running curve and there is an extreme big amount of documentation which is, I think, good to understand if you're really deep in it, and at the beginning it's hard. And it really takes a long time. It's the downside of it, wherever it's currently, I think, one of the industry standards to use and that's a really good point to have an open source tooling for creating embedded devices and where even the commercial companies are participating. And yeah, security companies supporting the MetaQ5 layer, we are supporting the MetaQ5 layer, and so it's much easier than years ago to integrate a device. Okay, I also added one page of references. I won't read them, that I think one of the most important starting point if you want to read something, especially is your project documentation, that's a website where you see a lot of links for the quick start guide, for the full reference, for the bit back reference. And one thing I just remembered, if you ever come to this bit back, look for bit back layers. I am not sure if it's in there. Okay, that's all I wanted to tell you, and I'm happy to take questions. So this talk, I just want to, actually I'm doing a similar stuff on Arch with the ASB and everything is built up in batch with YAML, receipts, and building this stuff into layer FFS, and then I can combine the layers to an image, but is it in the background, basically, working like this, or is it another solution? Right. First of all, in the background with Python. So bit back is completely big Python tuning. I'm just thinking about the image creation. I'm not sure, well, for every package you are creating, you are building it, you are splitting the package into smaller packages, for me it's really similar to what Steading's doing, so splitting step, and then you're populating the this route. And I think it's always taking the most recent versions as long as they didn't change. If you're doing real stuff, well, you get a dirty, you know, so it's good that you have to clean, but well, it's really installing it and extracting the files into a system route. I'm not wrong, but I think the layering doesn't happen. The layering doesn't happen on the crisis level, but like conceptually, only basically metadata, so basically on the input to the system, I do it on the Python system. The layering system is really a configuration layering system to make it easy to make adaptations for other layers. So you should never get this situation where you change the recipe from a layer but you make an append. So you have a very documented and separate layer that you want to change something, and if it's something pokey, or really done at crucial steps below, then you should try to change it there. In the end, you will get problems if you get patches there, but it's really a configuration. That's comparable to the ASP, basically, to the system of arch. I'm not telling you, I'm only, I know how that thing is working, but not arched. Maybe it's similar, okay, thanks. At least a little question. Any more questions? Well, this is not a question, but I just want to highlight that the work that we're doing open kitty, a huge door to an audience that has never seen the kind of work that we've seen facing open source, that the industries that are actively looking for creative development, so the developer, application developer assistance, it open house the door for companies that have been traditionally very close source and they are getting into open source, companies that have been to environments where Q is the king. So, I think we have a lot to offer in many of those industries and I also think that it would be a great area for KB to get into the spotlight again and bring a lot of energy from people that we not have and that we not know what we have and what we know. So, I would like to see more and more people that these guys putting effort on that, reducing the gap and then going to these big corporations and getting some money from that, it blows that gap, but that's how we can store it. Also, my type of question, are you using the queued, embedded long time, license rights team, the local queue? Well, depends, here I'm on my own with my KB head on it and then I'm for sure using all the open source. So, using the open source version on the embedded system? Yeah. Okay. It's interesting for me, I'm from the KBQ, the foundation and always the topic comes up. What is embedded because it's supposed to be run time licenses, it's just perfect for the local licenses but you're using the open source version of the embedded system. And, well, from the North from all of us, I still want to ask, where's the difference? What is in the non desktop, the license agreement with queued? For me, the embedded space is not covered by our agreement so it's not subject to the foundation. Well, it works. Yes, it's the same, technically it's the same. And if I may ask a totally different question, I'm really wondering how you want, if this approach you're doing, your space is creating images that can flash on the system, it's cool, but how do you want the long term handle the life cycle? There are many different devices out there in the world and these machines, they run up to 20 years in the field and how do you want to, with all these many upstream projects, how do you want to deal with that? Especially if you've got security and last but not least, are your devices locked down? Can I have them? That's a really big question but that's usually, well, here we are providing infrastructure and that's a question for the people who are integrated and bring it into the market. For the updating process, we're sure you need some specific system like two partitions or three partitions system where you flash onto one partition and then switch the partitions and go back if something goes wrong, maybe with a golden image where you can fall back if everything breaks down that you don't have to set the field technician with the lock down. That's a completely different story. As far as I know, nobody had tried in the automotive sector to do it really with GPS me or LGPS me or stuff. Technically, it should be possible. I'm not sure how it should be legally but that's something I can't answer. So you're locking down or not? Well, the rest of the device we have here are not locked down. No, I had a glance at that because I'm one of these machines. Will I have access to the kernel? Can I change the kernel? Can you do a security update? Well, that I cannot say. That's for me not to say and I'm privacy. I mean it's different from different companies. Some of them are important but how it's a class? That's a simple question actually. It's an embedded. I mean, is it the definition of embedded that the application comes with the hardware? That's what I've heard, that's the definition of embedded. You know the story. Yeah, but I think we all know the story how the GPL came and how the performance started to structure. It was not about a PC, it was about a printer. Yeah, but here we are talking about, well, what I just said was an open source license. It's for private area. That I don't have a commercial license. Company, we have commercial license for sure. And well, I don't know anybody who tried it yet with open source licenses. For sure in all the terrorization rules and the problems, yeah, sure. But here I'm going to explain how to. That's the last question. What are the different ones? So the LGPL, in general, when you want to use the LGPL, you can't lock down the device. And you have to provide instructions on how you can just check a few fibers in the open source fibers. That's simple. Yeah, sure. That's simple. That's why I love that the mobile companies don't like to write this instruction by the commercial license. That's the reason for LGPL3 and GPL3. And that's also the reason by VSKD8. Support is that the KD8 free soft foundation goes right away to LGPL3. Let's have a round of applause once again. Thank you.