 Okay. Thank you, Marissa. Thanks. Thanks everyone. I'm Nicholas. Joseph and myself are very happy to be here today to talk to you about the Yocto project. We want to, I mean, we want to give some, some sort of a high level introduction to the Yocto project and to show you how you can actually get started with the project. So as was just said a little bit about ourselves. So Joseph is a software developer and is also one of the Yocto project ambassadors, which is like some special title that we give to keep people within our community who are actually doing a lot of very good things for the project. Whether they do advocacy work or helping newcomers on many different things, but that's that's a special problem for the projects. We are very happy to have Joseph as one of our ambassador. I'm Nicholas. I work for Linaro and I'm also the Yocto project community manager. And yes, so we are going to be with you today for for this live mentorship series with the Linux Foundation. So today, because of the title and how we are going to run the event, we expect attendees with very different backgrounds, so we expect people with software and other background. So we will start a little bit with some introduction about what the Yocto project is about. And then we will do and we will try to make like a live demo of actually what it is to use the Yocto project. So if you don't know the Yocto projects, this is kind of an old truck that I've been using. If you have to remember one thing about the Yocto project is basically the thing that helped people put Linux in orbit on Mars. So it's an old truck, because nowadays we have Linux on Mars, but still, I mean, if you have to remember something that's basically how it was used a couple of years ago. So more, more seriously, what is the Yocto project? So it's basically an open source project which is hosted by the Linux Foundation since 2010. It's a collaboration project. And what it does is that you provide all the tools, all the processes, all the packages, everything that you need to make your own specific custom Linux based system. It was embedded when it basically 10 years ago it was mostly about embedded and nowadays we see the Yocto project being used in more and more places beyond what we actually started with embedded only. So one thing which is also very important it's actually completely independent of the underlying architecture as we are going to see today and it actually works and can be used on any kind of hardware. And we are going to actually make a demo and look at the RISC-5 today. Yes, we have, I mean, obviously our own developer community, we have like, I mean, we have some statistics here with like thousands of developers who have contributed to the project. We have many companies also contributing to the projects, to the source code of the project. The Yocto project is a large project which is made of many different tools and sub-projects and you might have heard about open embedded and build bake which are the key. Sub-projects which are actually part of the Yocto itself. We will have, I mean, we will see more, I mean, about that in this presentation. As I mentioned, the Yocto project can be used for platforms that work on ARM, X86, PowerPC MIPS and now since recently we have also seen initial support for the RISC-5 architecture in open embedded and that's what we are going to do today. The project itself is organized with like some administrative leadership and technical leadership. We have companies who are just sponsoring and founding the project. We have different level of membership from silver to platinum, like pretty much most of the Linux Foundation project. This company make up the governing board and is in charge of making the big decisions of the project and the finances of the project running the infrastructure and of the project as well. The Yocto project is also governed by technically by the technical steering committee, the TSC, and members of the TSC are elected mostly by the governing board. Just to show, this is the current membership of the Yocto project with the various levels and as you can see by looking at the few logos there, it's not just about embedded. A few resources before we deep dive. So we have the Yocto project website. If you want to learn more about the project, the structure of the project, and if you want to find the first pointers to get started and get to know us. The mailing list, if you are serious and want to start working with us and doing some collaboration with other users as a developer, we have plenty of mailing lists and we welcome new people. So feel free to use that. And the very well known Yocto project documentation, which has been a large effort from us and from the project since the very beginning to what you have like an outstanding documentation for the project. The Yocto project is very often seen as something which is complex to get started with, but hopefully we have some really good documentation and that you will be able to use. And obviously we are there on social medias. So you can feel free to follow us look at what we are doing on Twitter on LinkedIn on YouTube and Twitch. We'll see what we are doing today. I mean it's going to be a live session. So Joseph is going to guide you and show you how we do and how we use the project. And it's something that is actually very often doing. I mean, in what we call the Yocto project live coding session. So on a monthly basis, pretty much. And all the sessions are available on the channel, YouTube channel for the project. So we have I think more than 20 hours of live recording of Joseph doing something useful with the project. So if you like today's discussion, you can click on that link and you will get to see Joseph even more. So now this is it. So this is what we want to do today. So we want to do a live show. So I'll give the stage in a few minutes to Joseph and it will open a terminal and it will show you how to get started. So what we want to achieve today is building and booting a completely new system for a risk five architecture will use I mean for like practical reasons will use QMU. But everything will be built from source and everything will be customized using the project. As you can imagine, it's probably something which is extremely difficult and something you probably don't want to do at home. And obviously, we are going to show you that this is not the case. That's very straightforward to get started with the project. On that side, I think it's up to you, Joseph. So we can take question. I think it's been said, if you have any specific questions and at any point of time, you can use the chat. And we try to do our best to monitor the question and answer, and there will be time after the demo and after the Joseph stock to actually take more questions as well. So thanks, Arisa and Nico for kicking us off. You will get my terminal straight to you in no time. So exactly now. As already pointed out my name is Joseph. In my daily life I am a developer software developer for industrial controls at RSI electronics. And through that work I got into the Yachter project and I gradually did more and more and more until I kind of leveled up to the ambassador status, which means that all of those funny social media media things that Nico just mentioned is usually like cost by me and I guess that that that's a good wording. And with that, let's start out. Anybody here has probably already seen seen the live coding sessions with better quality. They were with 480 interesting. Okay, I'll take questions anytime interrupt me whenever you feel you feel like it and let's get started. Okay, to get started with with the Yachter project we usually grab Pocky, which is what we're going to do as the very first thing straight hot off the, the Yachter project service. And while it pulls down, I'm gonna play me. Okay, let's go. Pocky, essentially is a reference distribution. It pulls and pulls in and ties up the things that Nico just explained it pulls in bit bank, which is the task runner that manages all the things that have to be done. It pulls in OECore, which is a huge load of metadata will get to what metadata actually is in, in a couple of minutes, and some special sauce. And again, as Nick could just mentioned, for, for QMR to be usable, we need some initial support and some some scripts around it, which is exactly what Pocky throws into the mix. And once we have all those things in one, we can get started. We do have a checkout. And from that checkout, we need to set up. Come again. No, okay, that was just sounded like some electronic music. From, from, from, from the initial checkout, we need to set up a build environment, which actually is just like setting up some environment and variables in the specific terminal session that we are in. That means you don't have to have all of your machine configured for a specific build, you can have as many bills as your heart does permits, you just have to remember what is in each session. So Pocky brings a script for that, which we are going to source right now. Okay, what has happened. Let's have a quick peek into the environment. And it's, it's actually not that much. Basically, basically, it adds a couple of things to the path. The just mentioned scripts and BitBag plus BitBag environment. We are not going to need that for today. And after that, you're essentially set to build your own Linux. We are building for QMU today. And we will be with the cool kids, we're going for 64 bits. So machine is QMU risk 564. BitBag is is our task runner, and we need to tell BitBag what we want. And core image minimal. I'll get to that in a second. Okay, and now it's time to talk about metadata. You see parsing recipes. Recipes are essentially the smallest unit of metadata that we have. Metadata means data about data. And in the context of the Yachter project in the context of building a Linux distribution from source. Metadata means data about the source. You know, it's data that tells BitBag how to treat and build a source. So something that is actually usable falls out in the end. And this means there's some generic things around, like all things that use auto tools as a build system, or all things that use CMake. And there's special things around, like all, like for each source tarball or source repository that we are actually going to use. And you can see now that things are like going wild. This is because for each part of the metadata, it is essentially split up into tasks. Tasks are things that have to be done for the data, for the source. And this usually but not necessarily means, like fetching, getting it from source, fetching, getting it from somewhere. Patching if necessary. Configure, you know the old triplet, like configure, make install. So a lot of sources need configuration. Then you need to build it. You need to install into the target. You need to package it up. And then in the end it is hopefully in a working state that you can actually use. In the context of the Yocto project again, or in a greater open embedded context. Why did I just talk about packaging? Because one of the outstanding features of the Yocto project is that it's not just building a Linux system, it's actually building a Linux distribution. There's one really specific distinction. Once you're building a Linux system, it can mean that there's only like one tarble falling out in the end that you can boot. Okay, that is cool. But how do you upgrade one specific source package on it? That's complicated. If you are building a distribution in the sense of the Yocto project, every source package that you are actually building is going through the whole flow of a package manager like RPM or depth compatible. And only from that, the root file system is constructed. And with that, you have just seen everything is finished. We did just build a Linux system for RISC 5. That was crazy, right? And I see the question, is the Git repo the same for all the hardware? Yes, it is. We will get to layers once I finish the demonstration. Because I think we have a lot of time to discuss things later. I am going super fast today. Okay, we have built, you have seen tasks, you have seen packages. So now to prove that I actually built a Linux system, I also need to run it. And as promised, I'm going to do it in a QMU for RISC 5. So again, machine, including typo, machine equals QMU RISC 5. I'm trying to learn touch typing and I'm horribly failing, I tell you. No, again, I just mentioned Pocky brings scripts for QMU and we're going to use one of those. So run QMU is essentially like the canned special source of Pocky to run stuff in QMU. And if I would kick off that right now, you would see a lot of error messages. Why is that? Because this is an SSH session. This is an SSH, sorry. Talking at the speed of Steven Rosted is demanding. Okay. So this is an SSH session on a virtual instance on the Google Compute Engine. And I don't have a graphic output. And the QMU in the standard configuration goes to an STL output on X11 and we don't want that. We're going to go for no graphic, including typo as promised. And we don't want to use sudo and all the crazy stuff for networking. We just want to show that things are working. So it's the magic slurp thing that just tells run QMU. We want user space networking. And there we go. Fingers crossed. It boots. Mission accomplished. How fast did we go? How long did it take us to build our Linux system? 20 minutes. Including disclaimer by Marisa and introduction by Nico. I think that's pretty awesome, right? I can log in. Let's look at PROC CPU ID. So, you know, I'm not cheating you. We're really on a RISC-5. And it tells you the same. I'm going to give you five seconds to chew on that. Okay. Would it guess it? The date code says Wednesday, September 8th. Which is obviously not today. So, how did I do that? We actually used a tiny cheat. Because no machine that I'm aware of can build a Linux distribution from scratch in that time. I do have access to pretty beefy build machines like half a terabyte of RAM, 256 cores. And they can do it. Compiling and building and packaging, everything up takes way too long. And so what did we do? We actually used one of the other super, super, super cool features of the Yucca project. Or to be more precise of open embedded technology and BitBag as a whole. We used caching. So, you can not only cache the downloads, which means like pulling stuff from Git repositories and tar balls and everything. You can also cache whole build artifacts. And we're, again, back to the packages. This happens on a per-package basis. And we call this the estate cache. And what we do, what Nico did, while I was like blabbering away at us at you. We're going to look at that. He actually made two small modifications to the configuration that just told BitBag, okay, Joseph has already built that. Go use that. And I'm going to show you that right now. All of the configuration of the Yucca project of a Yucca build of a specific build. Let's let's put it like that happens in the local.conf. And we decided to skip that. So if you only watch like the first 15 minutes of what I did, if you follow the first lines that are typed, you will get a working build. It will just like take substantially longer, but it will work. And starting from that, we can do modifications or understand what is actually going on. So in local.conf, we can basically change everything. So what is there? There is the machine. The machine is conditionally assigned. So that's why I could just like pass it in on the command line. And here is the small trick that actually got inserted. The download directory is something that I pre-populated. And the other, the estate is also something that is pre-populated. But beyond that, no tricks, I promise. It is only to speed up the build. We're not going to talk about some deer or anything of the more deep diving things. Just again, it really everything goes into a package manager. We're going to look at that in a second too. And we are by default using RPM. And other than that, I think that's about it. That's about the core of things. BitBake looks at the metadata, fetches all of the sources, does its thing, and also puts them on the side in case you have a subsequent build so you don't have to start over. Because we're now going to do some small modifications just so you can see in action. And then you will see that compilation and everything really takes some time. I see one question, how is the number of cores being set? This is happening by run QM. There are several machine definitions or QM environment definitions. And in the case of RISC-5 for 64 bit, it's just a four core machine. If this is of some greater importance, drop us a note later and we'll show you the line where things are happening. Okay, so now, we're going to do some smaller modifications now because I told you things are being packaged up. And once they are packaged, things get into an image. So there's essentially two things that you can build via BitBake. There's recipes that you can build directly. Those are producing packages and you can build images. We have just built an image and now we're going to build something that is not in the image. So I don't have to type it over and over again. I'm going to set QM RISC-5 now as a real value. QM RISC-5. Okay, so my usual demonstration thing is BC. Which is like a terminal calculator and I'm going to use time if it's around. Hopefully it is to understand the build and you will see that it takes quite a bit longer. Shall we? I think we have time left. We don't have to hurry too much. So once this is going through, we can inspect the artifacts that we see. Okay, finally I messed up. Sounds good. Okay, let's look at what actually comes out of this. So inside the build directory, you have to think of everything that happens during a build as temporary. Because it is derived from source, you have the source. This is what open source is all about. If you have the source, everything else is temporary. We can throw it away at any time and we can recreate it. So basically everything we built is in temp. And there's a lot of stuff that would need some deeper diving. But there is BC. BC is already around because the kernel needs it. That's it. Okay, but with the drill down more and more and more, we can see that per package. And I usually look at BC, there's RPMs created for specific architectures. And from that comes the images. We go into deploy because images are meant to deploy it. And core image minimal. Let's look at it. That should be it. The font is a little bit too big. But actually, I think you can see that the root file system is like only a couple of megabytes. Okay. And one other really, really cool thing that we are really proud of is that per image, there comes a manifest and the manifest tells you exactly what packages. And here, here we come again for for the distribution and packages thing. So if you go through the whole flow from source to package to image, then you, because you have to take every package as a single and put it into the image. Then as you have to, you take every package as a single and put it into the image, then you know what actually ended up into in the image, you know what its license and this version work. And with that, let me look at one, one, one, one, one, one, one question. How about our final reproducibility exit. This is really one of the things that we are super, super proud of and especially Richard is is like our God of reproducibility we are doing great with that. So if you just as Dennis, I think it's Dennis. If you if you have the same sources, and you build it again, it should be binary. Why is the same. Um, okay, the supporter Linux distributions that is not exactly relevant today. So, okay. Now, we have looked at what went to the into the image. We have looked at what versions went into the image. Now that let's look at what licenses went into the image and then we are going to actually add something to the to the image. Okay. And hopefully I'm not messing it up now image license manifest. Yeah, there we go. So this is all the stuff that went into your build. This is this is one of the things that makes that makes it super cool if you are using your to fuel your product that you actually sell or handout, you know, a lot of a lot of open source licenses referred to distribution and usually distribute stuff that that you build on on your toe and that's that's the point where it goes beyond embedded and that's why why we chose the title. A lot of people are distributing containers. And the day that I build a container, I tore it up, and I send it to somebody else. I am effectively distributing a Linux distribution. And in the moment that I'm doing that, I am bound by all the licenses in the container that doesn't only apply to embedded devices that applies to containers, or to to CDs with distributions or development environments that applies to about everything. And this is where we really shine and that's where we go beyond embedded. We build a coherent Linux distribution, and we can tell you exactly what's inside and we can reproduce it. Okay, and now we have, we have talked about packages we have talked about why we need packages where we've talked about why packages are cool we have talked about that packages make up an image. And I think we have like a couple of minutes left to actually expand on an image. I think we're going to do it. I don't think we, we shall go the long route. I think we might actually do it. I have 10 minutes. Yay or nay. Yay. Yay mean yay means more fun and more time to mess up. Cheers. So, our metadata is organized in layers. This is, I think I promised to talk about it later. And now it's later. Layers mean that you can actually like, add stuff in. And this is this is another super cool feature, because you can be a software vendor you can be a board vendor you can be like, whatever, if you are, if you have something that you want to support for your customers in in a build, you essentially provide metadata for it. They can pull it in and tie everything up base it on top of whatever set up they have. So it's like a mix and match strategy. And then, yeah, you, you create your, your own distribution using the mix and match layers that you get and adding your own. So that's what we're going to do right now. Create layer. 11. Does that work? Okay, that bake layers create layer, add layer, So I do now have a directory called meta 11. And I'm going to make recipes 11 recipes 11 and by by convention. The recipes are structured in recipes like functional group and under recipes there's directories for all the specific recipes and their supporting files or an images directory. So we're going to go for images and there we're going to start out with one more. Now I can't see anything because the chat window is overlaying the terminal. Okay, meta recipes extended probably images core image. Cp score images core core image, minimal death. Gonna copy it here. Cp. And we're going to call it 11 image. That sounds cool right image baby. And let's edit it for us for a bit. This is what I just like couple look from install. Is BC. I'll explain it in a second. Yeah, I know but but but talking and typing all of the same is really, really like complicated. Okay, I think I got it right. Okay, so what did I do. I started out with simple image that is already coming with pocky copied it over into my layer. I need to extend the include path, because now I'm not referring to to a file right next to it, but to something in a in a in another layer so I need the whole path in the layer. So the description that I just modified is only like a human readable short description to to understand what the image is meant for. And then metadata consists essentially of a lot of functions and variables and one of the main variables to control image generation is image install and I append to image install so whatever comes from from the core image install right at the top I append BC to it and hopefully this works now I have I've talked so much and messed up so little that this actually can only fail, but we will see so time. Let's look at bake LFM image time to have a drink and look at at the at the jet. Is it best to start with a poker is a repository. I could not could not follow. I know something is always happening. Assuming that you already have a target platform. Yeah, it depends. If you usually depends. Especially on the quality of your target platform because there are some vendors that are handing out really good metadata that you can like instantly use. And there are some vendors that had not really really really crappy metadata and in that case, you should just start out with a plane pocket and add your stuff on top until it does what you want. And reference distributions by manufacturers. Yeah, it depends. And you should know the BC, the space before BC is actually needed, because append does not add spaces to to its content. And therefore, it is needed. Otherwise, the strings would be like slammed together and not make any sense anymore. So, could not include core image me more. Let's see. It is being found. I actually don't think that the. Ah, yeah. But it's not the minimal it's it's a death that one is not being is not being being parsed correctly because I just copied it over. If that's, that's the only fail I did in this whole session, then I'm happy. Okay. And I've been bitten by by one of the off of our recent changes, because overwrite and therefore also append syntax has as changed only like four weeks ago and I, I am not used yet to it. So images. And, I guess, insert. If I get it right now, then we should end up with an image that actually brings BC, hopefully talking so much. I think I've covered like double the content I do in in a in a usual live coding session because in the usual live coding sessions. There's only like 10 people looking at what I do. And today we've got like 10 times the 10 people. So thank you everybody for being with me. I'm going to build up with an external tool chain. Don't do it. Seriously, it's, it will just cause you pain. There's, there's a couple of hints you can get from a meta arm, because they, they are like, they like their external two genes but if you really think it's a good that they know it is not. We do have a build run QMU. Again, I set machine in local dot com. No graphic as usual, flip. I'm going to boot up again. And so let me check my notes if I have covered everything I wanted to tell you. Yeah, as pointed out the tool tool, the external tool chain, we are like building our own tool chain that suits the distribution as we needed it. Yeah, I think we've covered everything. And now we see, as you all know, the answer is 42. I am on time. I am finished. Thank you everybody for having me. I guess that's it. And yeah, well drop drop us notes drop us comments around for for another couple of minutes if there are no questions you will have to listen to me bubbling and doing other things. This is, this is a threat. I tell you, you don't want that. And yeah well follows on the social media look at the already existing live coding sessions. A new live coding session will be announced really really soon. I have not yet made up my mind on the topics to come. Yeah, and with that, I think I'm going to give back to. Yeah, quick question. Yeah, if you have your SSH history session for all the commands you have run, giving that to people might be helpful. Come again I didn't get that. All the commands you ran on the SSH. I mean on the terminal history if you get get the bash history and post that that might be helpful. Yeah, the no graphic and the and the slurp explanation you mean. Oh the bash history. Yes. Okay, let me see if I can, if I can, before you get rid of the terminal so that's how I was kind of rushing to interrupt you almost. Okay, yeah. Sure, let me let me check if I if I can but that shouldn't be a problem. Sorry. Yeah, looks good. And yeah. I wouldn't want to like fiddle around with it right right now. Well, I hope people are still about to talk to me or Nico. Is there is there a preferred way where I should put the bash history shall I mail it to Marisa so she can add it to the notes or whatever. Yeah, sure. Does it work. Okay, sure. Looks like you already have a question in the question. Let me let me see. Thank you. When will we have a security dedicated session. I guess once you bring enough money to pay a lawyer that sits right next to me and keeps me from talking. Because there's no way I'm going to give you security advice. Seriously. Yeah, best practices. Yeah, it's it's complicated. I mean, the best security advice is trivial. Stay stay on top of a maintained branch and don't put back doors in. That's, that's, that's the whole thing that there is there, there are a couple of tools or things that you can add on top. I actually don't have real experience on on those. I mean, I know that as you Linux and comparables might give you headaches occasionally and might help you occasionally, but I'm neither an expert on those, nor do I have experience, nor do I have any recommendations. So I personally probably won't do anything on on security and well best practices. There's a fine line between between things that are considered real production know how and things that are like common knowledge and I try to share as much common knowledge as possible in any way, but I will not cross the line where the core production know how my employer is affected. And I hope you can understand or respect that. So other questions. No questions. I have promised to be around for for a questions for 45 minutes. I want to use Linux in the name of my Octobie's team get get in touch with with with the Linux foundation trademark. Things I guess, well, um, they have to be. I mean, is it is it a product that you that you actually advertise and try to sell, or I mean if you call if you call your layer metal Linux things, then yeah, so just because the question I think not everybody see the questions. So there was a question with someone can use the name Linux in the name of the layer and that's what I read. Yeah, it's a trademark issue. Yep. And yeah, you need to contact the Linux foundation I mean it's it's not something that we should relate to the project. Yeah. Is it possible to run a react to build on WSL to yes, it is. And I actually have have done it I think it's live coding session 16 hexadecimal one one X 10 so it was a happy birthday. I was building on WSL and I was actually running a yok to build distribution as a WSL container. So it is both possible you can build for WSL to and you can build on WSL to I think from done fell onwards. So this is explicitly supported yes. So while we talk, let me add something I mean first I mean thanks Joseph for your time. I have a question. We do have another question. Oh but one that I'm going to not going to answer how to change color image and TSTs. This is a rather complicated. They are actually a couple of really good presentations on that from the various yok to project the developer days and the project in May this year. It is, it is a rather involved process due to the complexity of the topic, but it is certainly many manageable so you would probably be better off to look at the kernel manual kernel development manual. And those presentations it is quite a bit beyond the, the topics that I usually deal usually do. Sorry. Okay, more questions how can, how can I use and how did I get this one I have no idea. How did, how did I cannot use a beer I take the glass and erase it to my mouth and then take a sip. And how did I get this one I actually went to the fridge. Okay, topic done. Okay, yeah. Okay, okay is a good question. I like okay questions. So, more questions. How did I made my start journey in Yachto. I actually started in 2011 when I attended my first ELCE and Prague and I just went to the Yachto booth with a friend of mine, and I was like, I have no idea what you are doing. And that's how I got my first conference tissue ever, and it was by the Yachto project. And that's how I started out. How, so, how would, how would I recommend to start off, of course by watching my tutorials regarding SPDX in, in OECOR. Sorry, I have no idea. Please, if you have, if you have more specific needs on that, ask on the mailing list and we will put you in touch with the people who know how many hardware boards risk have a proper support in Yachto in core Yachto. No, no real board. It's only QMU in, in the layer for RISC-5, meta RISC-5. The Beagle 5 has good support. But yeah, hardware is, is being complicated sometimes. So if you're interested in learning about that, talk to your RISC-5 hardware vendors, have them approach us, have them join us, and we will, we are happy to, to help them make things work. Okay, I think I have a couple of questions. Now, let me start. The application is usually developed and embedded in, in Linux. I have done a live coding session in getting started in C++ development. I think it was number 17, but don't, don't nail me down on it. I, I would recommend to start out with that one. And from that, iterate on further metal layers can bring about everything, Yogesh, but is there a way to export the version information for all packages in an image. I think I've demonstrated that at 4.5 p.m. my time, manifest in the deploy directory to Mike Frampton. And is it possible to get a version hash symbol? Yeah, that, that's exactly what, what the estate does. It, it changes once, once things. Jan asks how to manage your project at large. Many layers from many sources. Yeah, we know about that. And again, there is a live coding session on that. I think it was number 13, where I talk about repo, get some modules and cast, my, cast being my personal favorite. And it does exactly what you, what you're asking about, you define the layers that you, that you want, you define the revisions of the layers that you want to define the variables that they want to be set for the build. And then you can kick off everything in your CI CD pipeline. And Pedro asks us to add a set of packages to an image. Yes, you, whatever you do, never ever modify stuff in layers that you do not own. If you want to, to add modify, remove, configure whatever, just slap on your layer on top and add your things, there. Layers don't have to be big. I mean, later that I just created during the session as an essentially had like one payload line, it brought one image. And that one image consisted of two payload lanes lines. And that one image essentially consisted of two real payload lines, which is the, the, the require and, and the image of installer pen. Layers are cheap. Recipes are cheap. Whatever you do, don't modify things in Pocky or layers that you do not own, slap your own one on top, ever. Everything else is the best practice, which brings us back to an earlier question. How can I get training and tutorial for, for, for using that one. Look at the project.org page. There's an ecosystem tab and people offering services, get in touch with one of those. More questions. The best practice is about build folder as it contains conf local.conf. Again, this, don't, don't put it under version control, because you actually have, have absolute things in there usually, especially in people.conf, which we have not touched upon today, and in local.conf with with the directories for download and estate. So it's best to have some form of mechanism that ought to create those in a build pipeline. As already noted, I personally favor cast because it's meant as especially for that purpose. You have one configuration file, a YAML file that you can put under version control and from going from there, all of your build is being set up and and runs off. And that's what I personally consider best practice, but there are varieties. But I think we all agree on do not put local.conf under version control. Generally, do not put things into into local.conf that make the build more special than the necessary. Okay. Yeah, exactly. There's a Yocto project some summit coming up end of November. So I invite you all to to join us there. It will be awesome. I will be annoying you all there again. How to reduce the consume storage. Sorry, that's that's a downside building stuff from source takes takes CPU time and it takes storage. There's there's a couple of things you can tweak and twist here and there but generally you have to. You just need a lot of a lot of storage. There's no way denying that. I guess that that that that goes goes beyond the scope of the session but there's documentation on that so please head to to already existing videos on YouTube, or the manual. Will there be a recording. Yes, it will be on the Linux foundation website and I think my research told us it will be also on YouTube. I have a question in the q amp a brief about the stages of image stitching. Yeah. I think Nico, shall we spend one minute on it. We can of course, we can. Okay, so we have, we have only talked about the image as one like ominous thing that falls out in the end, which is obviously over simplifying. The image can take a lot of forms. In the case of q m o it usually is an x for a flat file system that q m o can use directly, but it can also be like tarbled up. It can be other file systems like JFS or whatever, and you know what recent addition is is wick, where wick stand is a is a is a is a like an onomatopoeic play on on on the words, it stands for open embedded image creator. This essentially enables you to to grab artifacts from from the build and put out a binary blob that can be flashed onto some form of storage. So that can go into into net image or onto an SD card or whatever. So the image format wick actually like only denotes. Okay, it went through the open embedded image creator. And for each target hardware that you want to use this for you have to define a week script. I think that's life coding session eight where I demonstrate that for for the beagle bone black that is the image is is a suffix that is sometimes used by proprietary vendors. This is nothing that that comes from the project as itself. Okay. Since it's quite, I want to come back to something you said which I think is very important to point the octoproject summit. Over the years, we have, I mean the octoproject has had its own mini conference and I mean most of the time we've tried to be close to the Linux Foundation event. In the past if we've organized death days. So death days is basically like it was like a day where we would gather people. I mean in the room like 1020 50 people in the room, and we have been like beginners and advanced trainings, and these trainings are have been given physically physical event in the past. Obviously, over, I mean since the last two years we haven't had that much. And we have started to do like virtual event for the octoproject so we have started to build what we call the octoproject summit or your project conferences and so on. And it has been quite successful event so far. So if you if you are interested in the octoproject I mean what we encourage you to do is to join us for the next one, which as Joseph just said will be planned on November 29, December 1 and December 2. So to be a three day event, and it will be a mixed bag of trainings for beginners and beginners and less beginners. There will be a day of presentation where we will have speaker like I mean Joseph and orders from the community will talk about what they do with the project what they want to do with the project I mean how they use the project or anything it's just going to be like a conference. And yes, so that's that's basically going to happen soon. If you want to learn about this event. I encourage you to just follow us on the social media we are going to announce actually very soon. The next event. We are going to also call for speakers. So if you want you can also try to contribute as a speaker. And yes, so that's been quite quite popular event. What we've done for the last two events is we've recorded everything and everything is also on the YouTube channel so if you go on the project YouTube. You will see all the presentations and actually all the trainings that we've given at the last two events. And yes, so I mean a lot of the question you have seen today have answers actually at the previous event so you can watch the videos and then you can come back with more questions, of course. Okay, so we could stay 25 more minutes if there are more questions. So yeah, just be here. That's another very, very interesting question Nico from a market marketing standpoint because the question reads. Do you think Yachto is over engineered comparing to build route and even open WRT and the the down to earth real quest real answer is no. It serves a different purpose, because both of the of the, those are the build systems have their strengths and their use cases. And it's, it's not a question of complexity or a question of engineering. It's a question of solving your problems. And build route, for example, as it has been mentioned is is a great tool. I have been using it myself for quite some time. If you, and that's why I rift quite a bit about the packages distribution thing. Builder is a great tool to crank out a root file system that you need to that you want to to kick off real quick. I mean, the learning curve of Yachto is really, really steep. There's no denying that. But you can you can achieve amazing things with it. And if if you don't need those amazing things if all all you want is a root file system that matches a certain architecture for one board that is right on your desk, then Yachto is not for you. I mean that that then it's not over engineered it's overpowered that that's a major difference. If you don't need a lorry truck to get one bag of sand for for your children's playground, you can do it, but the lorry truck is not over engineered. It's overpowered that that's the major difference. So, if you if you want something for your tinkering one of you, one of her kind board on your on your on your desk that you that you are never gonna like update for security reasons that you're not going to support for like 20 years. Then, then it might be that Yachto is not for you. That's, I think it's fair game to name it. And so it's not like not about liking one thing more or less. It's about choosing the right tool for the job. And if, if you if you have a project where you where you have to support some hardware platform that has to pull in some some some software stacks from from different people. And you have to like roll out updates on a per package basis. For example, then, yes, then Yachto shines. If you don't need that if you have like one source package, and you want it to run on one hardware, and then you pull the network plug out, and you run it forever, then you don't need it. Because, I mean, this layers mix and match things is is is a super powerful thing. If you need it. I know that doesn't have it. But if you don't need it, then, then that's no, that's no drawback, then you can use. So it's not about engineering or about liking. It's about understanding your problem. And once you've understand what, sorry, once you've understood your problem, then you can pick the tool. Don't do it vice versa. That's not going to work out. Okay, so people are merging Yachto with Android those days. I've, I've never seen that. Seriously. Nico. No, and I don't quite understand the question. I mean, Android is the distal, what we could say, I mean, it includes its own build system and Yachto is a build system that actually you can use to build the distal that you want. So maybe if you can rephrase or maybe add more details, we can take that further. Does Yachto provide a package manager? It does provide a package manager, you can, you can instantly like use one. Frank Westcast, who presented on the last YPS Yachto project summit on in May, exactly about this. How, how to speed up your development using packet in target runtime package management management in, in production. Well, again, it depends. I personally prefer image updates, but again, don't don't pick on favorites pick pick on requirements. And you have multiple platforms, similar things in place. I don't understand the question, Yogesh. I'm sorry. Next question by Mike. I have any resources about who build a root only files with them with doctor. Yeah, sure. Open your local dot com and type image underscore features plus equals string read only root FS. Now you have your root read only root system. Seriously, I'm not kidding you. Image, maybe we can expand on image features. You mentioned it. Shall we do that? I mean, we have 20 minutes left. Shall we build a root read only file system? I'm fine with it. At least what we could say is that I mean, the image feature is, is actually a feature of the, the metadata and the configuration that we can use to actually configure specific parameters, which are for the image. So read only is one of them. It's actually going to do many things to the underlying the resulting image that actually is going to implement whatever is needed to do the read only but there are different features. So which apply globally to the image. I don't think we have. I'm not sure we have time to make a demo but I'm just going to kick it off. I think it shouldn't take more than like two or three minutes. Okay. So, if you, if you, if you give me screen share. Sorry, read only root FS. You can see. I'm, while it builds, I'm going to talk about the image features that Nico just mentioned. There's image features. And that just added read only root FS there. Bake 11 image. Just to discuss for the one image. What about Ramathas? I have no idea about Ramathas. Not at all. Never heard of it. Okay, so image features are like special keys that you can set for your image to to be tuned for for specific use cases. One of those keys is read only root FS, obviously, another key is tools SDK, which injects a whole SDK tool chain into your image, which makes it obviously like this, but you can build in target. And we're going back to the best practices thing. This is not the best practice. This is, this is a bad practice. Don't build in target, because we want such root FS is you can but another cool thing is tools profile, for example, which pulls in Okay, let me just look at this. Could not be configured offline. Okay, I finally have a proper fail during the session. Okay, sorry. It should be that simple and it usually is but I guess, because we're surfing on master and on risk five as a really really new addition, something might be going wrong here, I can't figure it out on on the fly. I'm sorry. If at all possible, I'll provide a small follow up to Marisa and if not, well then I'm sorry. And, yeah, image image features can can like inject major behavior behavior changes or package selections. And they are they're like kind of a big switch that you can throw on a specific image, and they are predefined. So there's no there's no like imagining your image feature right now because you think like images images fancy is cool and you want it. It doesn't work like that you can you can create this throw features on the fly. But again, that I'm not going to cover today, because I already covered it in one of the recent live coding sessions when it comes to building your own debug distribution. You want to feel you might want to check out that session. Okay. Sorry for interrupting unique about like one questions that come in. I usually jump on those. That's okay. So, sure, sure, do you want to talk for a couple of minutes about the program itself. Yes, any more questions. Yeah, we still have, you know, close to 10 minutes. Looks like there is another question that came in. I'm going to build your with lbm. Not, not exactly lbm, but there's metal clang. Just Google for it, or somebody might can can can drop in the link. It's, it's just what I what I explained about layers. In this case, somebody in this case, somebody who likes clam or lbm creates a layer that can inject a lot of infrastructure into a pre existing build. And in this, in this specific case, it's it's Kim roge. I hope for the pronounced him closely enough so he feels proud about it. Good guy. If you ever get a message by Kim on the mail on a mail. Don't, don't be like angry because it's super short. Be proud because your question was interesting enough. So he took time to answer you. Kim is one of of the other like brains behind a lot of things in the project and especially layers around it. And he does a lot of really cool and really crazy stuff. He's he's the maintainer for metal risk five actually, and metal clang. Um, yeah, you can build with LLVM. There's even magic in there to distinguish between packages that can be built with clang or LLVM and cannot be built with LLVM. So yeah, we got that covered. Thanks Nico for the link. You have a similar mix to multiple platforms. Yeah. It depends. Sorry. You shouldn't worry about the exact call commands you have to type, you should, you should understand the requirements. So, um, that's really a complex question. Let me digress a bit into into the into the image versus distribution topic, because I do see distribution actually means like you, you present a form of interface that your application can use. It can be binary or, or only like API compatibility, but in you, if you, if you say similar Linux distributions, I inserted that there, then you usually mean you have some form of application, or setup that you want to to, to several hardware platforms. So you would be probably probably this is all under under lots of lots of guessing here. You probably want to build one distribution that goes to several hardware platforms. And in that case, you would have one common setup and built for for several machines. You could do that in by chaining calls to bit bake your image. I demonstrated machine equals whatever bit bake stuff. And you can do that for machine. My board a bit bake stuff machine, my board be big big stuff. My machine, my board see big big stuff and you end up with a temp directory where under temp deploy images, you have my board ABC and the resulting images. This might suit your use case. It really depends. If you, if you have that requirement, it might be, it might be useful to actually get in touch with somebody who has already maintained such a system. There are other package managers than RPM. Well supported this IPK, which uses the depth image format, but without big database, the ITC package manager, I think, I think the York to project even is, is maintaining it. And there's some support for depth packages as is, but I have some some. Well, non optimal feelings about it. Let's let's put it like that. It should be there, but I don't think you should use it. So generally, we support RPM and and IPK those those are really well supported and I can tell you that I use IPK every day and in my in my day job, and it works really, really well. Okay, no on package managers, just because something just because something uses a package manager that does not mean you can install random random packages from from somewhere. This is a common misconception. Some, some people think that by setting the package manage to Debian, they can magically use apt get and like slap in some package repository for Debian and no, it doesn't work like that. It never ever will be working like that. You know package the package manager means that the tooling that gets your sources from the build to the image. The package manager does not magically make some stuff from the internet from some repository make on your board. No way. And why would you want to change your package manager. It depends. It depends on your specific use case I personally use IPK because it feels Debian ish and I can inspect resulting packages for dependencies or whatever using TPK to TPK G. But that's about it RPM for for the common use case where you have no runtime package management. It doesn't matter. So I got on bubbling again. I guess we could end with common misconceptions about the actual or things that people think about the October that are not necessarily true package minute yogurt asks pass cut package manager we're talking about is about the note it's about the deployable system. We're only only talking about the deployable system. We're really I don't know does not care how stuff got on your development system. Once there's a tool chain and the requirement to require tooling. It doesn't care how stuff ended up there. You can you can run. You can actually. Now it gets crazy. You can actually build your toe on your toe. You can build an image that boots on x 86 that has no package management at all, but is capable of running another year to build. So the package management that we are talking about here is always the package management of the resulting Linux system and that could be run on the target and nothing else. We're not never ever talk about the development system. Yeah, exactly. That that's one of the common misconceptions that I get run sometimes. And the question goes like this. How can I use your toe to build a custom Ubuntu distribution. The answer is, you can't, because we're not an Ubuntu customizer, as well as we're not a Debian customizer and not a center stack customizer and not an arch Linux customizer and whatever. It's about building your own distribution. So, again, it's about understanding your requirements. If your requirement is to use Ubuntu, then use Ubuntu. That's the goal for the project. If your requirement is written down as this has to run on Ubuntu, then we are not what you need. And building a custom Linux distribution really means we take source and build stuff. We do not take other distribution things and artifacts and magically mangle them and put out your custom distribution. That's all about. It's about building custom from scratch. And the smallest possible root FS for a specific target is no. Because if I want a root file system that is no, then I define, then I patch the kernel so it doesn't jump into init and stay in the kernel forever. I have no root file system. So the question is not exactly making a good point for, but for real life use cases, you can easily achieve root file systems in single digit megabyte ranges. Again, it depends on your use case. If your use case mandates that Node.js is to be run on the root file system, then it will be like 30 megabytes plus X. If your use case mandates that there is system D and Apache running on it, it will be 30 megabytes plus X. If your use case on the other hand mandates that all you need to do is kick off one binary that is suited is located at been in it. Then you can easily go to go down to a couple of hundreds of kilobytes. So it really depends. Sorry, Yogesh, the question has no answer. Smallest, smallest possible root file system for a specific target. Yeah, name the specific target, name the requirements, name the smallest softwares that that's that's business know how. And sorry for wording it that hard. That's your homework to do. I wanted to say that, as you said, it's not one to what you can get it out of your career. You should not use your to build new one to but what I thought the October I'm very new to your so I was trying to understand. What I understood from your clothes to get some image which is very specific to that particular hardware with many more software, which are to be installed which are only necessary for the customers to use that will go to the production system is that correct. That is correct. The, it's about defining. So, so once you have your metadata set straight, you can define that your image actually just gets that application and from the dependency tree that this application spans out so an application needs libraries and maybe an application so you basically define what you need. Don't install don't define what you want to install define what you need. And if you're if you define that I need only that one application, then the resulting root file system will be as minimal as possible. Okay, that, okay, that's actually a good point. I have to distribution will not work like. Okay, here's your, here's your standard distribution and you put on things on top. But a standard yet to your distribution is. This is what you want. And what do you need in order to make this work. And then we're going to add everything. The standard distribution is constant constant, a yok to image, not a distribution, you have to image is constructed. It only puts in the things that you actually actually need to to fulfill the requirements that you stated, and now we're going back to one of the topics that I mentioned earlier. I talked about containers. And one of my personal favorite topics is building containers for super specific topics. And I'll actually be speaking at the, at the chairman. Okay, you are all entitled to last now, JavaScript for two weeks, where I talked about building hyperspecialized node JS containers with Yachto. And this essentially is just what I described. I want an image where only no JS is required. And I even define no JS doesn't need internalization. And I define, I want no JS to be built against muscle instead of jealousy. You can end up with a container that can only run no JS. It's like 25 megabytes in size. And you can't even get a shell in it, because there is no shell. You can't hijack the container and get to bash because there is no bash. And by definition, a properly defined image in Yachto is always as minimal as possible. That's, that's, that's the bottom line of everything. No things get pulled in just because we like them. Things get pulled in because you, you tell your to pull them in. And this is, okay, this is another common misconception people showing up and saying, okay, I've got this image from, from my vendor, and it's, it's like super bloated and this and this and this and this and this is everything in. And how can I remove it. And the question is not is wrong. The question is not not about how, how to remove stuff. The question is, why, why do I add things first so I can remove them later. Don't add them at all. Start with an image that only defines what you want. Don't even add stuff first, then you don't have to remove anything, and you end up with a much, much slimmer image. Thank you, Joseph. Thank you, Nicholas. This is a great session. Thanks for joining everybody. And we are leaving you with you some resources for your continued learning. Thank you so much. Thank you, Lisa for having us. Thanks for the invitation and well, take care, everybody's your own. Thanks everyone. Thanks everyone.