Okay, hello everyone, we've made it to the end of the conference My name is Davis Roman and I am so excited to be here in bobao to talk to you about OS tree for the uninitiated what you need to get up and running with OS tree on your next project Okay, so who am I I'm an embedded links engineer I have 16 years of experience on home security security products and access control systems and now I'm in the automotive space Previously I was employed at Honeywone Residio and now I'm at Lucid Motors in February Originally, I'm from Queens, New York and now I'm based out of Fremont, California I've been using OS tree for many years across multiple projects one of which is a product with over a million devices So let's imagine a scenario It's your first day at mega corp and your boss hands you a next-generation device bound to change the world It's the eggminder the device the smart egg tray when you forget how many eggs are in the refrigerator So you're not one egg short for tomorrow's omelette You're told it runs in bed of Linux But before you can begin developing your collapse on this device you'll need to first update to the latest and greatest It's been on the show for a while So it's probably very out of date out of habit you'll reach out for your USB thumb drive But you notice you can SSH into the eggminder because why wouldn't the eggminder support SSH, right?  So let's take a bird's-eye view of OS trees update process After typing OS tree admin upgrade dash R OS tree determined the required remote and ref just think branch for a moment using the origin file The summary file was pulled from the OS tree server, which specifies the latest remote and commit a Diff of the commit metadata that was pulled and stored onto the local OS tree repository and the commit was deployed Meaning a hardlink form was created in the deployed directory pointing back to the OS tree repository The uemv.txt file was updated Reflecting the deployment as well as which kernel and in it remfs to use a 3a merge occurred in slash etc Slash var was selected according to the state route After the reboot the uboot bootloader mounted the file system and imported the uemv.txt Into its environment The deployment file was passed via the kernel args and the kernel was booted with the init remfs The init remfs determined which deployment to use via the kernel args and mounted it onto the physical sys route The init process intruded into the deployment becoming its new slash and Proceeded with booting into user space as usual You got all that right a lot just happened. So let's take take one step at a time Let's start with a few objectives We'll begin by discussing prerequisites for understanding OS tree We'll discuss OS tree versus lib OS tree and why it's hard to search on YouTube and Google for OS tree related content We'll discuss package versus image versus differential upgrades We'll discuss some different OS tree architectures We'll get started with an OS tree enabled Raspberry Pi 4 build using the yachter project and We'll discuss pushing to an OS tree server, even though it's not natively supported. We'll discuss that later We'll talk about basic OS tree command line basics and booting into an OS tree deployment and finally yachter integration So as far as the prerequisites if you're a user in OS tree meaning an application developer or testers There's none. Just learn a few OS tree command line basics, and you'll be fine However, if you're a system integrator BSP developer or system engineer, there's heck of a lot more to learn You have to know about overlay fs's hard links to roots bind mounts and it ramifaces you boot and the yachter Build system. So now's probably a good time to take a quick snap of the cure code I forgot to mention that in my intro slide So because I have got a lot of content and spring and links sprinkled all over the place so I'll just Wait a moment Okay, we from got it. Oh, I see one more and All right, we'll dive into OS tree now So originally call it created by Colin Walters from Red Hat originally for the good old continuous project You can think of OS tree is git for file system trees. So some of the features Transactional upgrades either it's fully applied or not at all Rollback so once you're on the latest commit if for some reason you decide that this commit is has some issue You can roll back to a previous version Also, Austria allows for replicating content incrementally over HTTP Also, you can you can do parallel installs of more than two bootable deployments and you have the binary history on the client and the server You have flexible support for multiple branches and repositories and it's designed to be resistant to certain power laws Austria was initially driven by server needs both later ported to the embedded Linux base Austria is primarily focused on the delivery and deployment of file system trees So Austria was originally called Austria, but has since changed its name to live Austria Basically to get away from putting too much emphasis on the command line tool itself Austria refers to the command line tool itself while live Austria. Obviously, it's the library many blogs and tutorials use the terms Interchanging really which can be very confusing. I know that firsthand Austria began in the desktop Operating system space, but it's since been ported into the embedded Linux use cases Most videos and online documentation is skewed towards the desktop at least for now So see here are some of the projects that have that that have OS tree I was initially I initially became familiar with Austria via the automotive grade links project Here's some other great projects that I encourage you to check out So let's discuss about package versus image versus differential upgrades So you're probably all familiar with package based upgrades rpm apt yum So some of the advantages so requires low bandwidth easy to use lots of lots of information available online As far as the disadvantages every system is slightly custom since there's no strict control of what can be installed on specific versions And it's unreliable in the absence of a human operator It's not power safe and could corrupt the system at any time As far as full system upgrades The advantages it can be very it can be tested exhaustively because we're dealing with just one image EXT4 or squash a fast that gets downloaded onto a device It's easy to reason about because like I said, it's really just one file that you're downloading and then flashing onto a partition And it can be far safe with innate with a be configuration Disadvantages, of course, it consumes a lot of network data Even if you change one config file, you're still downloading an entire file system And it decreased the lifetime of store of the storage medium due to excessive writing But now atomic differential upgrades or OS tree So the advantages requires minimal network bandwidth as only the difference is downloaded It's power safe due to its transactional nature and the smaller the difference the faster the update takes But here's it here the disadvantages it requires a reboot most folks complain about this one HTTP request for each file that we don't have and We can't perform cryptographic verification on the block level here I've provided a link from the talk that Colin Walters gave as far as a compromise between image and package based I think he makes a very good argument and I encourage you to watch this which watches video Okay, so we've discussed the prerequisites Package versus image versus differential updates and now let's talk about the different OS tree architectures so They're not necessarily called this in the documentation, but overuse. This is this is kind of what I've converged to So push pull offline distributed. Let's start with the poll So for the poll you can think of you can think of three in this case three embedded Linux devices that are all Austria-enabled they each have their own copy of the oyster repository in the file system They have some sort of OTA OTA update client That that is internet enabled and connects to some public Austria server This public oyster server is populated by this fictitious company called megacorp with apparently only three developers their CICD process commits to a local oyster repository and those commits eventually get promoted to the publicly available oyster repository So some some of the advantages for the for for the scenario So it relies on oyster server publishing a summary file that all clients can periodically monitor if you simply care of just about just being On the latest then this is a very straightforward path But the disadvantage is is that you don't have strict control over which commit gets downloaded onto specific devices Here's a quick tutorial just on this So we start with a raspberry pi that has an oyster-enabled image Like I said for those in the back. I apologize you can't read this But I promise it should come out better in the recording So in this case what we're gonna do here is we're gonna add a remote the command is OS tree remote add We give it a a remote name in this case I've chosen pocky then we give it a URL to an oyster server in this case. It's just a server on my local network Then once the remote is defined we use oyster remote summary pocky The the raspberry pi goes out to the oyster server queries the summary file to to get a list of refs and available commits So in this case is f621 Then we try to do an oyster upgrade, but that commit the commit on the raspberry pi is the same as the commit on the server So there's nothing to do at this point. No update is available But now let's try something in the background will add the h top package to our yachto build and Then push to an oyster server. Now. I know I haven't mentioned what yachto is in two sentences what I can say is yachto is a System with metadata that allows you to create your own custom Linux distributions. It is not a Linux distribution. It is a distribution maker so now At this point after adding the h top package pushing to our server We call the oyster remote summary pocky command again, but now For the raspberry pi for ref the commit has changed DC f8 So now on the raspberry pi we say oyster admin upgrade Po only and we see we get we get the metadata plus additional content objects And we do a diff now we can diff the previous commit of the ref with the current diff of the ref and now What we see here is that among the files that are getting added h top is with is isn't the list Now at this point if we choose we can do an oyster admin upgrade Which allows us to boot into the new into the new operating system with h top installed So that was pulled. Let's talk about push Push is very similar to pull with a twist So again, we go back to her example with three embedded Linux devices that are oyster enabled with their own oyster repo With their OTA clients they go out to some public oyster server that gets populated by this mega-corp thing But now the difference is that the developers have access to this other entity called an old OTA campaign system and Now what are the advantages with an OTA campaign system? Well, you get that fine-grained control over which devices get specific updates because that system You can push metadata to the specific devices and within that metadata is an individual oyster commit You can do regional based upgrades and you can carefully control the rollout To limit exposure in case of bad OTAs Also, you can closely monitor the progress of your update campaigns Disadvantages you get more There's more upfront cost to develop such an OTA campaign How but but there are many off-the-shelf solutions such as to rise and quarter Quick tutorial on this So again a bit of preparation work now will add the nano package on in our inner yachto build Push to the server just so that there's a difference and there'll be something we can pull So again on the Raspberry Pi the commands oxtree pull pocky remember that's so that's the remote name And then we give it a specific commit so previously we use the summary file now We're using a specific commit that we Retried via an out-of-band method which would be that OTA campaign system. So now after this We use oxtree diff And we use our current current ref and this commit and then if we can see that nano is among the binaries that are getting downloaded At this point if we so choose we can deploy and boot out of this new commit So offline Again, we have the three embedded Linux devices, but this time there's no internet connection So at this point our options are to roll a truck and get a service person out to our devices the advantages here it allows for air gap systems and improves it in theory approves ability to Ensure that if that the firmware is only used by approved individuals provided that you trust them, of course and Disadvantages are you can't push from her over the internet obviously and Physical access is required but not always possible Think of a buoy in the middle of the ocean and it can be very expensive to visit customer sites Quick detour on this for offline mode We'll begin with some bit of preparation as we've done before we'll add the jq package on to our yachto build and we'll push to the server So there are two modes for offline. The first is using pull local So on the build machine will copy the oxtree repository directory onto the USB drive and then insert the USB drive into the Raspberry Pi Then we'll use the oxtree pull local path to our mounted USB drive in this case It's slash mount slash USB slash oxtree repo and then the second argument is is the ref So the the commits are pulled and now we can say oxtree show raspberry pi 4 We see that the commit is 0 7 eb Which has just been pulled if we diff the previous commit with the with with the current ref We see that jq is among the the binaries that are getting pulled and lastly we can deploy if we wish and boot out of this new system But now there's also static deltas So let's talk about that So for static deltas we generate a static delta file on the build machine and then copy down to the raspberry pi How do we do that? We use the oxtree static delta generate with the ref name in this case raspberry pi 4 we give it a from and a to and Then we give it a from from commit to to a specific commit and then we give it the file name We we look at the file size So in this case is called jq underscore delta and it's only 245 kilobytes So relatively small we copy the file onto the raspberry pi and we apply it So the command is oxtree static delta apply offline and then a path to the static delta file We ask it to show us the commit and we see this new commit. It's the same as before so from this point forward It's all the same the difference is well, let me finish this So we do the diff we see the jq is among the binaries that will get downloaded if we boot out of this out of this deployment So now the difference between a delta and the poll local from before is for the delta We're dealing with just one file one binary delta file Whereas previously we're dealing with an oyster repository with with metadata As far as which to use its use case dependent so it But but they'll achieve the same thing Okay, so now lastly the distributed option So again, we have the three embed links devices that are oyster enabled, but now they're on a local area network So it's peer-to-peer and they use MDNs So they can find each other on the local area network and they use DNSSD for service discovery So they can figure out which repos are being served and who has what refs They do this using collection IDs their collection IDs are universally unique identifiers relying on reverse domain name handles an example is a classroom of devices where all devices get updated as soon as a newer device appears on the network as In my opinion, this is the most interesting distribution scheme. However, I don't fully have this working yet, so I don't have a tutorial to share I'm sorry However, here are two links that go into more details on the distributed option in Austria. I Encourage you to watch them So now let's talk about getting started with an oyster enabled Raspberry Pi for build using the octa project For the sake of time, I won't be able to go line by line. However, I will provide a high-level overview So we'll start by setting up the repo tool This tool is responsible for bringing the source and and installing it onto your local machine We'll set up Yachto for a Raspberry Pi for build We'll use the meta-updater from the advanced telematics get repo using the dump fill branch Then we'll do a repo sync This is what it should look like once the meditate once the source is pulled. I apologize. I realize you can't see this in the back apologize But it comes out better in the video. I'm sure So while doing this work, I realized that there was a boot issue And the boot issue is that it couldn't find a configuration node This is an error in in new boot but not a problem because the issue was was was straightforward and I generated a patch and threw it up on bit.ly You can apply this patch like so and then at this point you can continue So we kick off our Yachto build by sourcing the ENV setup.sh using Raspberry Pi 4 as your first argument Then in our local.conf we'll set the Ostr update summary equals one variable So that every time Yachto builds generates a commit the summary file is updated accordingly And then lastly, we'll we'll kick off our our Yachto build using bit-bake core image minimal When the build is done, you should see something similar to this picture here So let's talk briefly about the newly generated Ostr repository that that was just minted by Yachto So if you're familiar with Yachto, you'll recognize this this directory structure build temp deploy images Raspberry Pi 4 Ostr repo so in this directory if we use the Ostr refs command we'll see that it uses the Raspberry Pi 4 ref If we use log we see the newly generated commit f621 and if we briefly look at the structure of this repository excluding the objects directory because then otherwise it would just be massive screenshot What we get is a folder structure where we have a config that describes the type of repository Raspberry Pi 4 file under the refs head directory that that indicates the commit that is the ref currently points at and a mirrors and a remote directory very similar to to get because Ostr is get inspired If we cat the config File we'll see that it's a type archive z2 Meaning that this is an Ostr repository that can be served over the network so clients can pull from it And lastly if we cat refs heads Raspberry Pi 4, we see the commit that this ref is currently pointing at So now at this point you want to put your Raspberry Pi The way we do that is that we use the flash image script that's inside the meta-updater Raspberry Pi 4 layer The first argument is the device of your SD card So in my case when I put that into into my laptop it came up as SDA On on yours. It might be slightly different the second parameter is the path to your wick file So here's an example of what it looks like when I when I ran it on my machine So once your SD card is complete you plop it into your your Raspberry Pi you allow it to boot Here's what you should see OTA enabled Linux 1.0 The login is root no password very secure So let's talk about pushing to an Ostr server So now When you're doing your initial experimentation Ostr I recommend that you use the same machine to host your build software Along with the Ostr repository itself But eventually you'll want to adopt a more formal process dev staging and prod So more more than likely you'll have different machines for for for each day each deployment process The problem here is that Ostr doesn't natively support pushing to a remote server However, the Ostr community has written a tool to address this gap So we'll be using the db Nicholson github repo for Ostr push Let me illustrate how Ostr push works. So we have a development machine and Development machine that you can imagine is what's on your desk and then an Ostr server Maybe some machine on aws or somewhere So when Ostr push is started it starts a local hdp server providing the contents of the local Ostr repo on the development machine The development machine then connects the Ostr server via ssh and tunnels the hdp server through the hdp server port through the ssh connection The Ostr receive command is executed on the Ostr server with the url and tunneled hdp server The Ostr receive then creates a temporary remote using the url and pulls the wraps from the development machine At this point the commit was pulled and the Ostr server is up to date So I've provided the the uh, how to configure server and your development machine. However For a lack of time, I'll just provide a high-level overview So on the server we'll provide we'll install the Ostr push project Using the db nickelson git repo. We'll initialize an Ostr repository Then we'll install patchy 2 or nginx or whatever web server you prefer so we can serve up that Ostr repository Then we'll we'll configure the the dot config slash ostr config file. I've provided some reasonable defaults in this diagram here Oh, and by the way, I've installed this on the boon 2204. I just So as far as the development machine Uh, very similar idea. We install the Ostr push git repo Using the db nickelson github repo We'll create a little script so we can define all the variables that are necessary At this point you can set up passwordless ssh login. This is optional But uh, I would recommend because it makes life easier And then as a final test to make sure that the integration is done properly We we can we can run ostr receive dash dash version and if we get the version back then you've performed the steps correctly So now at this point, let's try running the ostr push command from the development server So we run the script and the script shows us the commit that we're trying to push And it performs a push On the ostr server We can use ostr dash ostr space refs to show us the ref that was just pushed We use ostr log raspberry pi 4 to show us the commit that was just sent This commit matches the commit that was sent from the development machine We can also use ostr summary dash v to see the summary file And we see that the summary file is also in agreement with the commit that's on the server and came from the development machine As well as the time that the update was was sent If we go to the server, we can see that the commits are being served over over htp So now let's uh quickly cover command line ostr command line basics So you're given an ostr enable device. You want to see if it has ostr Well, first of all, I would I would check to see if it even has the ostr command after that You check ostr admin status if you see the following output It's a very very good sign because there requires a lot of machinery to get this far So ostr admin status shows you the commit of the currently deployed uh current deployment You see the index number so you can see if that commit was deployed more than once You see the operating system version if you're only using one os then then this will just always be the same name I mean the version is configurable And the ref spec which is a combination of your os tree remote and and the ref which in this case is raspberry pi 4 And finally we can use os tree log the commit to verify uh these details Oh, okay, so we use os tree log. It shows us the commit But more importantly it has the content checksum So this is a really cool feature that os tree has because os tree supports content promotion So if you have a dev staging in prod So you want to take a commit that starts on dev And and after testing you want to promote it to to the next stage You cherry pick that commit, but then your commit changes. That's not good for for traceability So os tree provides you a content checksum, which is a representation of the file system itself excluding the metadata So even though the commit will change as you cherry pick them the content checksum stays the same That's really nice for traceability And then finally the date version and content id is configurable and you can I encourage you to make this as descriptive as you want As far as pulling specific commits from the os tree server as we discussed before the command is os tree pull We provided some remote name that we've defined in uh in this case. It's test server colon along with the commit that you're trying to pull We'll see the the number of metadata files that were pulled Along with the content objects or the files that that is trying to pull The size of those files and how long it took to do the download to do a download As far as deploying the commit And uh, so you you you do os tree admin deploy After a reboot you'll boot out of this new commit. Um, and so you'll be in this new file system So a word on cleanup so over time the client's os tree repository grows and can eventually fill up the file system I've seen this firsthand It's recommended to periodically run os tree admin cleanup which removes commits that are not associated with deployments So a question can changes be made to os tree up to to slash user So slash user is read only by design It follows the user merge design pattern and it looks something like this diagram to the right So instead of having physical slash bin slash s s bin Folders those folders live under slash user and instead what we have are sim links. So Slash bin is a similar to user bin slash s bin is a is a similar to to slash user s bin Now the advantage is here is that we that the the file system is consolidated under one directory allowing allowing Allowing it to be easier to make that one directory read only as opposed to making a bunch of directories are only uh, so This results in the majority of the file system being read only Um, I if you would like further details into why user mergers used I I recommend this open susa Talk called user merge and beyond But now how do we develop in the system you ask so os tree provides os tree unlock command And what this does is it applies an overlay over slash user allowing for modifications This overlay looks like this diagram to to to the lower right where the lower is your read only file system That is the pristine version and we don't want to touch that Then we apply our changes in the recorded in the middle layer And then what you see is is the top which is the combination of the read only plus the modifications So This this unfortunately, this is removed after a reboot, but it is nice for quick tests Personally, what I use is the os tree adam in dash dash hotfix So again, it applies the overlay over slash user However, it's persistent across reboots allowing for for application development But keep in mind that after deploying a new commit the overlay overlay fs is thrown away So what about slash etc So can we change slash etc technically yes, but here be dragons So os tree uses the three way merge scheme and my experience is a big source of frustration for os tree beginners The tldr here is that if a file and slash etc slash foobar is locally modified and later slash etc slash foobars Updated in a newer build your locally modified version of slash etc slash foobars kept yikes However, the new the the new read only default version of foobar is stored in slash user slash etc So os tree provides a command called os tree config diff Which inspect slash etc and informs us what has been updated modified and deleted relative to the current commit So if slash etc slash foobar shows up as modified all you have to do is cp Slash user slash etc foobar into slash etc if you run os tree could os tree admin config diff It'll show up as no changes. So now now you're good For an explanation of why we're using the scheme Uh, I've provided a link to a blog post from calling walters And at the very end. I think he describes it very uh succinctly He says if you modify config file in any way that wins So Another question does os tree protect against corruption due to power loss? And the short answer is yes The long answer is please watch this drew mosley's Webinar are implementing power safe atomic up Over the year updates and here's a link. I fortunately don't have time to go over this But I promise you it's a very very good webinar and I know someone will ask so I figured I drop it here so Let's talk about booting into an os tree commit So how do we boot into an os tree commit? This diagram I tend to lose a lot of people once I go into this diagram, but I'm going to try very hard to explain this So we have a on on the left. We have the storage side and on on on the right. We have the runtime side So on the left think of that as the physical sys route I'd like you to think of that as an emmc or zsd card On the right you have the virtual sys route think of that as the login And so when you log in you type ls and you see something that that is that shows you a typical file system layout So back to the physical sys route At the top level all we have is slash boot and slash os tree So this is very unlike anything that conforms to the file system hierarchy So in slash boot slash loader. We have a unv dot text This file describes what kernel what it didn't run my fast and what kernel args the boot loader Should use in order to to uh to boot the kernel properly Um along with that We also have the the uh device tree the netrum fs and and the kernel under slash boot slash os tree slash uh os os commit So the os commit uh is also special here because os tree does not put the boot artifacts as part is the file system It keeps it separately for for for the reason that um It we don't want to we don't want to change those artifacts unless they've actually been changed. So so they're kept separately Then we have the the uh the the uh The hard link farm. So what this is is a this this is what you'll eventually charude into It's a representation of your file system with hard links that go back to that that link back to your os tree repository Then we have var var is shared across the different deployments and that'll get mapped onto your virtual sys root the the uh The root of the physical sys root gets gets bind mounted onto slash sys root So we are able to access the os tree repository when we're when we're logged in in our virtual uh sys root environment So how did we do this? How did we get from the physical sys root to the virtual sys root? So here we dive into the net remf s So the net remf s helps us with os trees chicken and egg problem The kernel cannot start the net process until it switches into the deployment And it cannot know what deployment to use until it mounts the file system And to mount it it needs to know which deployment to use and so on and so on So on boot up the boot loader you boot in this case Instructs the kernel to start the net remf s which contains a tiny file system With an init script whose job it is to parse the kernel command line to figure out which deployment to use So that's the get os tree sys root function The init remf s mounts the physical sys root and again think emmc sd card onto slash sys root The init process performs the switch root using slash sys root From this point forward slash s been init or even system d continues with the deployment as its new root You got all that right? So lastly yachter integration So for yachter integration Fortunately the meta-updater Layer does a lot of the heavy lifting for us It built it among other things it builds the target and the native os tree binaries So the native binary uh lives on your development machine and it's responsible for creating that commit That will later get pulled by the clients the build target version of os tree is what gets installed onto the root of s that gets installed in your devices So after after building the net remf s, uh, sorry that is uh, let's see Okay, so one of the bb classes that are in the meta-updater layer Image types os tree bb class has a section that performs the os tree commit So as far as the commit it points the local os tree repository As well as the yachter root of s And the branch that's used so this whole time we've been using the raspberry raspberry pi for ref It will likely be different in your project And then lastly we can describe the subject in the body and and I encourage you to make this as descriptive as you like And then lastly we uh, we we check if the up os tree update summary variable is set Um, I I always like to keep this set so that the summary file is updated Uh, as soon as the commit is generated. We want the summary file to reflect that new commit so Some some more words on yachter integration So we need to prepare the physical sys root, which is that the physical representation that goes on your eamon crsd card We need to prepare the deployment sys root, which is that hardlink farm and it's located in slash os tree slash deploy slash state root slash deploy slash commit We'll want to make the boot litter and init remf s work together to boot the deployment This involves setting up the env you env dot text so that you boot nodes which deployment to pass on the kernel command line So you'll you'll first need to make sure to control mutable state in your system So what this means is that operating system and application binaries under user must always be read only An application runtime data under slash far should be read, right? Initial setup of files and directories in slash far can be created using systemd temp files during first boot And templated config files can live in slash user, but must be copied to slash far during initial boot apps should use the copying slash far Fortunately, the first three steps are already done by the meta-updater layer So here's some final thoughts and recommendations So history is powerful and flexible update technology I would recommend that you periodically monitor the size of your os tree repo Otherwise, it will eventually use up all your disk space. So os tree admin cleanup is your friend Periodically monitor the amount of memory used Especially if your root if s is larger than your available memory This may cause you to anger the out of memory killer at times. I've also seen this for sand Also use os tree admit unlock instead of just remounting slash user as read write whenever possible to avoid your file system and Whether to use pull push offline schemes is use case dependent If you forget all else, please just remember this Mutability is the root of all evil. Choose immutable file systems systems whenever possible hear my references And I'll take any questions I have two questions. It seems the first one. It seems like that for the full system update There isn't the support for dm verity And the second question also is there support for a b updates? So for the dm verity case, I actually Can't really comment on that as I don't have experience with dm verity But as far as the a b updates what I what I will say is So I was on a project for a long time where it was just one partition One partition that had the whole os tree repository Now I've seen another project where they're very concerned about potentially, you know, what happens during a partition corruption Where you have Two partitions with two os tree repositories that keep each other up to date that can work Do I recommend that firsthand? I'm not sure. Uh, but can you can you combine it with a b updates? Absolutely anyone else And thank you for that question. By the way, can you comment on os tree apply live and its limitations? Sorry, can you os tree apply live? So if I want to apply The commit without rebooting the host right, uh, so so Rebooting sorry applying the commit without rebooting. Uh, that's That's mandatory. So what I have seen projects do because That doesn't quite work for everyone is to separate the applications using using some sort of container technology uh with that then of course they could they could update their applications and Restart them at will but as far as not doing the reboot for os tree. I Can't think of a way to do that So does that answer your question? Well, mostly in a desktop use case like if I have to install some applications like if I install mvmecli then I have to use Apply live if I don't want to do a reboot. I just wondering what limitations There are when when I use the apply live command Oh, sorry is apply live like a desktop rpm os tree It could be implemented in rpm os tree not os tree. Yeah, yeah, because I'm not I'm not really familiar with os tree on the desktop I'm primarily focused on the embedded Linux side I imagine if you ask the desktop folks, they probably have some wizardry, but And embedded I haven't seen how to do that. So Any other questions? Yes. Oh, sorry. Let's let's wait for the microphone. Sorry Why the cleanup is not automatic?  You don't have a lot of space You really can't afford to have a bunch of commits around then. Yes, keep running Austria admin cleanup As much as you want Does that answer your question? Thanks. Okay. Thanks. Yes, sir Uh building on that previous question sure, uh, are the Commits small when there's not a huge amount of change from the previous one Hmm So that depends on your project If you're making lots of changes and configuration files, then sure it could be it could be small but I've been on projects where You had one gateway that was hosting an image for an android device And this could be many gigabytes worth for one file So It really depends on the project So now if you have two versions of that same entered version Now your your repo explodes. So you probably can only afford two or three different versions of that Because that image is is humongous But like I said, if it's just configuration files a couple little images And you have a mmc with a couple of gigabytes, then yeah, you could probably Probably keep keep a lot of it Around but it really depends on your on your case Does that answer your question? Thanks. Any other questions? Okay. Thank you everyone


Hello, everyone. In this one, I'm going to discuss about metabolic indicators in five to nine years old children. This is CNN's data, which was taken between 2016 to 2018, which was pre-COVID. And you'd be surprised to see how our children five to nine years old all are doing. And the reason I want to discuss this data, because when you have metabolic issues, metabolic issues means pre-divities, high fat in the blood, like triglycerides are high, blood sugars are high. That means there is an issue with complementary feeding. So we have to understand that what kind of food we are starting in children from six months of age, and then you will understand how they fare at around five years of age, five to nine years of age, so that if they are becoming metabolically unhealthy, that means food which was started at six months of age and whatever they had as complementary foods and thereafter is probably not healthy. So this is the basically percentage of children five to nine years of age who have high triglyceride level. Now triglycerides means fat, blood fat. That's what we check, triglyceride. And if adults have high triglyceride, that means they have more fat in the liver. And you can see here, if you look at the overall data of India, about 33% children have high triglyceride level. If you look at all these different states, this is statewide data. You can see that West Bengal, almost 67% children between five to nine years of age have high fat in the blood. And this basically denotes that probably children are having a lot more carbohydrate and also fried food. We will discuss more in detail in this course, but basically triglycerides increase when you're having high refined carbohydrate food and also fried food, specifically seed oils. And look at this Sikkim, Assam, Nagaland, this all Northeast states. And they all have almost more than half of children have high triglyceride level. That is very, very alarming. So that's why what we have done in all our recipes for children, we have not used food which are in excessive carbohydrate, like for example, wheat, rice, and also we have not shown any recipes which are fried. Some of the states are children who have high triglycerides are kind of, I won't call it low, but relatively low. So Kerala has about 16% children who are 529 years of age have high triglyceride. Maharashtra has about 19.1. So if you look at the average, average is about 33%. So if you keep the average over here, say Arunachal Pradesh, that particular line, if you draw a line over here, you can see that there are many more states which are higher number than average for India. And that also includes some of the states like Madhya Pradesh, Bihar, Himachal Pradesh, Uttarakhand, and also Jammu and Kashmir. So a lot of these northeastern states, as you can see over here, have children who have high fat in the liver, as well as in the blood. Now the issue with high triglycerides, that these children are at risk of developing diabetes, pre-diabetes, also heart disease, early on in life. So that's why triglyceride, it's important to keep your triglycerides in a healthy range. Now this one is basically children 5 to 9 years of age who have high blood sugar. So look at again, your eastern states, your Manipur, Sikkim, Tripura, West Bengal, have almost 21% children who have high blood sugar. This is pretty significant actually. That means every fifth child has high blood sugar. And these children are at very high risk of developing pre-diabetes and diabetes, and then subsequent complications of diabetes. Children who have low high blood sugar, these are basically Tamil Nadu state, Goa, Himachal Pradesh, relatively small number. But again, as you go down, you can see more and more states have children who are in high blood sugar range. This one is basically percent of 5 to 9 year old children who have high, like, selected hemoglobin. So here you can see, HB1C will tell you whether a child is pre-diabetic or diabetic. So this HB1C, more than 5.7, these children are basically, they have taken the data of those children. So you can see a state like Goa has 26.4% children who have HB1C higher than 5.7, which is pre-diabetes. So Haryana, Goa, Gujarat, Jharkhand, Telangana, these other states, some of the states, all these dark red colors are pretty significant number of children or percentage of children of their state has high HB1C. If you look at the overall data for India, almost 9% children between 5 to 9 years of age have high HB1C. So every 10th child is pretty much pre-diabetic. So no wonder we are called diabetic capital of the world because our diabetes starts from 5 to 9 years of age. As you can see, look at the number of children already showing pre-diabetes at such a young age. So this will have to be very, very careful and as you will start going through this course, you'll understand why children get high HB1C and what can be done, what recipes to recommend to children, even our home, at home, we want to make sure that children are eating healthy food, less of carbohydrate, increased protein and increased good fats. In this, I'm going to explain micronutrient efficiency in 5 to 9 years of age in our children in India. This is, the data is taken from CNNS, which was the survey was done in 2016 to 2018 and this is government of India data. So this will show us that how our five years old are doing in India. Micronutrients, as you know, these are all nutrients which are required in a very small amount and this is the basically all different state level data. This first presentation, first slide is on vitamin A. So you can see that Mizoram and Jharkhand has more than 40% children who are vitamin A deficient. Now vitamin A, as you will see in some of our presentation that it is mainly present in yellow vegetables and fruits but more than that, it is present in egg yellow and liver and other non-veg food. But you can see that almost two-third of our states are not doing really well in terms of vitamin A in children. When children are deficient in vitamin A, they have high risk of immunities poor and then they have high risk of infections. There are other kind of deficiency symptoms also and what happens when they are deficient that you will see in our subsequent sessions but you can see that most of the children are not doing well when it comes to vitamin A. Here is percent of children, five to nine years of age who are deficient in vitamin D. So vitamin D is basically predominantly you get it from midday sun. We have a very good tutorial on vitamin D. Do understand and just make sure the children are exposed to sun during between 11 to 2 p.m. Here you can see Punjab has 76% children who are vitamin D deficient, so it's a five to nine years of age. Uttarakhand has 62%, Manipur has 55% and Haryana has 45%. It's almost like more than half of our children in last four, five states are vitamin D deficient. So you want to be again very, very careful. Again, all these red states are pretty alarming numbers. So do kind of focus when we have the session on vitamin D. Here is percentage of five to nine year old children who are zinc deficient. Zinc we have created tutorial on zinc also, what happens? You can see over here Himachal Pradesh, 37.7% children are zinc deficient. Manipur is 35.3% children are zinc deficient. Zinc is type two nutrient important for growth, important for height, important for many, many functions, including immunity. So you want to make sure that, look at this all, so many children are in dark red and red zone. So you want to give food which is iron zinc. Here is data of our children five to nine years of age who are iron deficient.  Huge number of children, even under five years of age are iron deficient, but we want to see how they are doing at five to nine years of age. And you can see Punjab again has a very high iron deficiency and EMEA 50% children, 51% children are iron deficient. Rajasthan, Gujarat, Haryana, Karnataka, Maharashtra, you know, pretty significant iron deficiency in this children. Here is vitamin B12. B12 is very important for brain, for memory, for cognition, for IQ, for it's basically extremely important for brain. And you can see that pretty much a whole of India is already, you know, except for few states, you know. So you can see one, again Punjab is 32.3% five to nine years old are B12 deficient. Uttar Pradesh, Gujarat, Chattisgarh, Rajasthan, these are all the states which are lacking B12. And, you know, we want to make sure that they have food which are high in B12 so that they don't have B12 deficiency, okay.  Now, we do give IFA twice a week in children but despite that, we have a huge number of children who are folate. Folate is also very, very important basically for blood. It is also important for, you know, DNA, you know, for a lot of functions. So we have a, you know, we have a tutorial on folate also. And you can see Andhra Pradesh, Assam, Assam, Madhya Pradesh, Chattisgarh, Meghalaya, Maharashtra. There's all states which are, which have almost more than 50% children who are folate deficient. Some of the states like Goa, Kerala, Haryana, almost 20 to 30% children are folate deficient. Problem with folate is that if our young, adolescent girls, if they're folate deficient and if we don't kind of treat this folate deficiency with diet and with supplement, then they may have a risk of developing neural tube defect once they become, once they deliver. So the babies who would be delivered to this folate deficient girls, you know, young women will have an issue with the neural tube defect, okay? So we want to make sure that we tell mothers to start folate rich food right from six months of age.  Thank you so much.


Hello everyone, myself Sanjay Utke, Assistant Professor, Department of Electronics Engineering, Valchandra Institute of Technology, Solapur. Today, we are going to discuss three-phase star system. Learning outcome, at the end of this session, students will be able to analyze concepts of three-phase star circuits. Guideline, introduction, relation between line current and phase current for star system, mathematical expression for line voltage and the phase voltage, numerical based on star connected system, acknowledgement. Introduction, basic concepts of three-phase balance of the system. In the last video, we discussed delta types three-phase system. A system is said to be a balanced or rather than a system is said to be a balanced supply when the three voltages, three phases are having same magnitude, but differs in a phase difference of 120 degree. Similarly, a load is said to be balanced when these three loads are having the same nature that is R L, R C or R L C carries the same phase currents. So, in three-phase systems, you will find delta type connections or star type connections. Definition, line current, it is the current flowing between the two lines, phase current. It is the current flowing to a particular phase, line voltage. It is the voltage between two lines, phase voltage. It is the voltage across individual phase. The phase sequence, the order in which all these three voltages attains their maximum values. Generally, the phase sequences are y and then b. In between line and the phase currents for star system, for star system, line current is equals to the phase current exercise. In three-phase balanced load, what is the value of three-phase impedances? In the three-phase balanced load, all these three loads are having same value and the same nature also. In three-phase balanced load system, each impedances will have equal values. They will carry same currents, line or phase currents because in star system, we will find both line current and the phase currents are same. Mathematical expression for line voltage and the phase voltage. Here, I will draw a three-phase system. This is r, y and this is b. This is i r, i b and i y. This is a neutral fourth line. This is v r n. This is v y n and this is v b n.  These are the phase voltages. What about line?  These are the line voltages. Now, it is required to find out the relation between this line voltage and the phase voltage. For that, I will draw a phasor diagram or vector diagram. This will be v r n, 120 degree delayed by v y n and this is v b n. All these are 120 degree. For the sake of simplicity, I will not show the angle. So, all these three are 120 degree apart. It is required to find out the line voltage.  For minus v y n, I will draw this being minus v y n. I will find out resultant of these two vectors using a parallelogram method. So, this is line voltage v r y. Now, let us denote o, this point q, this point s. Let us draw a perpendicular line voltage. From point s, a perpendicular s p on line o q. This is say p.   So, finally, I can write this v l is equal to root 3 times v p h. It means that line voltage is equals to root 3 times the phase of the line voltage for a star connected system. A three phase star connected balanced load having each impedances z p h is equal to 8 plus j 10 supplied with a voltage 400 volts 50 hertz supply. It is required to find out the I p h phase current, line current, phase voltage, power factor, then active power, reactive power and apparent power. Since the system is balanced, it means that all the impedances, three impedances are having same value and nature. Let us concentrate our numerical with respect to a single phase. So, to find out I p h, it is required to know v p h and z p h. So, what is z p h? It is 8 plus j 10 plus j 10 plus j 10 plus j 10 plus 10 j z p h which is in a rectangular form. Since we want I p h which is equal to v p h upon z p h, it is a division. Convert this rectangular form into polar form comes out to be 12.81 angle 51.34 degrees. So, next what is v p h? For v p h, it is v l upon root 3 and so 400 divided by root 3 comes out to be 231 volts. Now, we can find out I p h. I p h is equal to v p h 231 upon z p h 12.81 angle 51.34 degree. So, in this way, using calculator we got the value of I p h which is equal to 18.03 angle minus 51.34 degree. So, this is I p h which is also equals to line current because in star connected system both I p h and I l are same. Now, power factor. Power factor it is equals to cos of 51.34 degree comes out to be 0.62 lagging. Here the power factor is lagging because the current is lagging. Why the current is lagging? Because it is an inductive circuit. So, voltage leads currents by this angle 51 degrees. Now, coming towards active power root 3 v l I l cos of theta comes out to be putting value of v l 400 volts I l 18.03 cos of 51 degree comes out to be 7.8 kilo watt.  Similarly, apparent power is equal to root 3 v l into I l put value of v l I l comes out to be 12 kilo volt ampere. So, in this way we got first of all I p h then power factor then p q s. Acknowledgment, text book, electrical technology by B L Theraja. Thank you.


Good morning. Good afternoon. Good evening and welcome to another episode of OpenShift TV. I am Chris Short, Executive Producer of OpenShift TV. And I am here with two of my favorite Red Headers. I just met them. Let's talk about Fedora Koros is our topic today, or FCOS as we might refer to it. Clement and Timothy are here and I'd like them to introduce themselves because I'm terrible at introducing people. So Clement, you want to go first, just alphabetical order-wise? Yeah. So I'm Clement Verna, Engineering Manager at Red Hat with the Koros team. And I've been a Fedora contributor for five years now. So I'm involved mostly in the infrastructure and also I'm in the Fedora Engineering Steering Committee. So looking after changes and what is the future of Fedora. And that's about me. Timothy, you want to go next? Sure. So hi, I'm Timothy Ravier and I'm part of the Koros team too. I work on Red Hat Koros and Fedora Koros. And I'm also the Fedora Keynote maintainer on Fedora, so which is like a key variant of Fedora Silver Blue. And yeah, I'm doing most things in Fedora right now and around that. Awesome. So what is Fedora Koros? What is the goal of the operating system, right? Like all those fun things. Tell me more. Good question. So we've got a small presentation that I think I'll share with you just to kind of Fedora Koros basics one-on-one. And I think that hopefully at the end of this presentation it will have a good idea of what is it, what are the goals and how you can start playing with it. So as you said in the agenda, what is Fedora Koros, what are some of the features, how it relates to REL Koros, and also the relationship with OKD. And we have at the end, we have like a small demonstration on how you can use Fedora Koros to deploy a metric server at all. And we will have time obviously for questions. Obviously, yes. And please feel free to ask questions or comments or anything during the presentation. And if there's a good spot for me to ask it, I will, or we'll ask it at the end. Regardless, your question will get answered. Yeah, don't hesitate to interrupt. I think it's nice to get the question as they come with the context. Yes, definitely. So Fedora Koros is currently an emerging Fedora edition. We're trying to become a fully-plated Fedora edition. Currently, it's with the emerging status. So it came from like the merging of the Koros, the company container Linux, and a project that was in Fedora, Project Atomix. And pretty much is trying to look at what would be like a specialized operating system dedicated to run containers. So Fedora Koros incorporates pretty much from the container Linux, the philosophy, the provisioning stack, and also a lot of the cloud-native experience that was in the Koros company. From the Atomix host, it gets all the ecosystem from Fedora, so the Fedora Foundation, like all the community aspect, the update stack, and also it comes with the SC Linux and all the experience around SC Linux hardening and security and all that. So if we look at the philosophy behind container Linux, probably one of the most important is automatic updates. You want your operating system to update automatically and not have any need for an administrator to log in and run commands. That's quite important from like a security point of view.  You want a way to provision your nodes and servers using, pretty much, they all start from the same point and they all live, they all have like a common definition and like a way to provision them. And you have like the same method for bare metal or cloud-based, so you can have like a mix of instances in your infrastructure. Yeah, everything in the immutable infrastructure. So yeah, if you need to change, you update your config and your reprovision. So those hosts are like very easy to just destroy and reprovision. And the main point is that everything that is like a user software or like workload or everything that you want to run on the operating system has to run in containers. So which makes the host much smaller and also the updates much more reliable. Awesome. So let's go through like some of those main features related to the philosophy that we just saw that. So yeah, automatic updates is probably a very important one. So to be able to achieve that, you obviously want your updates to be reliable. If you offer automatic updates and they break all the time, people will just like disable them. So the real focus of the project is to make sure that we provide reliable updates and we make sure that when your operating system updates, it doesn't break. So to do this, we have extensive, we rely extensively on CI and we're doing a lot of tests there. We're testing also on different platforms, on different clouds. For example, for example AWS, Google Cloud, we're also testing with OpenStack. We have a system of release streams that enable us to push changes to different streams and be able to catch like regression or to catch breaking changes early. So it doesn't come to the stable stream. So we have three streams, stable testing and next, we'll go into more details after that. Nice. And another key point is that there is a manage rollouts of updates. So the updates will be rolled out over several days. So if you have a fleet of Fedora Core OS nodes, you can maybe have like a couple nodes to try to update early. And the rest of your fleet to update at the end of the rollout. So you can kind of do some early testing on one or two nodes and protect the rest of your infrastructure. So I think this also enables us to stop or halt the rollout. So if we got reports from something breaking, it's fairly easy to just stop the update rollout and not impact too many people. And yeah, if things go wrong, we rely on the RPMOS 3 technology that we talked about just after. And it's very easy to roll back to the previous working state. So even if at one point your operating system is in a state that is not working or that broke, you can roll back to the previous working state. And if there is some work that will be done in the future to try to automate that rollback. So trying to have users specify some health checks and make sure that when the operating system reboots with a latest update, making sure that those health checks are green and just continue. And if they are red, you will just roll back to the previous state. We have a bit more information on the update streams. So as I was saying, we got like those three streams, next testing and stable, and next is pretty much the latest freshest. It's also where every major Fedora rebases happened. Testing is a preview of what's going to stable. It's pretty much where we're trying to catch any breaking changes that we didn't catch in ECI. And stable is where we want to offer this reliable experience where you can just stay there and be happy and let your node update themselves without rolling too much. So yeah, how it works is that pretty much the content that is in testing stays in testing for two weeks. And after this two weeks period where we can have like feedback, it will get promoted to stable. So the content that is pushed to stable usually is very well tested. So it's certain that we have the goal to publish new releases every two weeks. We are able to achieve that goal. We release every two weeks on a regular basis since more than a year now. And yeah, the stream next and testing is really where we try to catch any issues or get kind of the real life testing and rely also on users to report problems with the app. Awesome. So you can decode the version of Fedora of CoreOS and kind of have an idea of what you're running. So that just a quick slide to explain that, but pretty much in the version you have like at the beginning 31, 32, 33, that would be the main version of Fedora, so the base. Then you have the date at which the snapshot of the RPMs where was done. So at this particular date, we just took a whichever RPM version were available in Fedora. And then you have like the release stream so one for next two for testing and three for stable. So you got here the diagram that explained this like two weeks for motion and how the content is is propagated. Do you have any question on this yet. I mean there's, there's, there's a lot of questions about like, what was the, what was the origins of atomic. Like, where did that come from? How did that start all the way up to how is sent off streams related to Fedora CoreOS, if at all. Yeah, so. I mean, let's just run the basics there. Yeah, yeah. I mean, really, in terms of atomic, it was really linked to to RPMOS tree or so. And like trying to have pretty much having this idea of having a very small like operating system with all the core core application that you need. And be able to run any user application or any software using containers. So a lot of, I think a lot, a lot of the philosophy between atomic and core OS were shared when one of that both core OS company. I think it made a lot of sense to have those two projects together. So it's safe to say that for Dora core OS is pretty fast moving right with two week releases and everything right like you're pacing ahead of Fedora a little bit maybe. He wouldn't say that it's fast moving in terms of feature. Because, yeah, we, you want to have like this stability. So, right. So we will get because because your your operating system is immutable. You don't really go on your machine every day and run like DNF update or whatever. So, pretty much what you get every every two weeks is this set fresh of packages with like security fixes or just bug fixes and things like that. Really the key. A key point for Fedora core OS is stability and making sure that we don't break the stable stream so I think that's most projects right like to be fair. So it can also it can happen that for example, when Fedora 33 was was released the stable stream was still on Fedora 32 because we wanted to make sure that the switch when we are switching from from the base from Fedora 32 base to Fedora 33 base. Everything was rock solid and that the update would not break people's host and work. All right, so another main feature is the provisioning and this came from from chorus so Fedora chorus uses the ignition, which is a provisioning system and pretty much you have like the you declare everything that you want to you want to configure on on your on your host. And this is run at the first at the first boot of the machine in the internet fs and we just configure the host. For example, the user SSH keys if you want or like how the partitioning is done. And yeah, where maybe for people that are a bit more used to the RPM world and like where you would have used in the past kickstart or cloud cloud in it for cloud, you know use ignition. Got a bit more details here. So ignition is itself, the configuration is the json document. And so yeah it runs it runs once when you first put your your instances and it runs in the internet fs when when you configure the machine. And here you said yeah I was giving some example about users but yeah you can create file system units configured with user books partitions, create red arrays format system so you can do a lot of configuration there and just tune your, your Yeah, and if the provisioning fails the boot fails so this is something that has to work otherwise. There is no point to boot in the system that would be half provision or half configuration. Another of the configuration for ignition is for the, it's to be easily consumed by machine. And this is usually not necessarily a good thing for humans so json is not super easy to, to work with as human beings and to modify. There is a tool called fedora coro s config transpire fcct that allow you to write your config ignition configuration in your mall in something that is a bit more human friendly. And this will transpire the emerald to json so you can keep your emerald file with all your configuration in git. And just transpire this to json before before applying it to, to you. There was a question about you know why Jason and I'm, I am basically answering in chat like this is designed to talk to machines.  So, if you're editing the admission files by hand, that's like an anti pattern I feel like sometimes right. Yeah, so yeah you don't want to to touch the json file, you really need to use the sec and make. And it's also a good way to force having this, you know, every change you make, you committed to your git repository. You don't really want to act quickly, make a change quickly in your json file, run the provisioning and forget about it. You want to go through making the change in your YAML configuration committed to git and have some type of CI and maybe your CI is actually doing the transpiling from YAML to json and even the provisioning. So it was made to, to be kind of GitOps, very GitOps oriented and making sure that every changes you make are stored and tracked in your configuration and your git repository. So FCCT is that human to machine interface basically right. Yeah. I think we had plans to have a web service that does that also currently it's still just a CLI tool. If anyone is interested or if we have the time that might become just a service. Yeah, there's a Docker image somewhere, a container image somewhere to run this as the container to as a web, web service, but it's not on any official server yet. Yeah, Timothy, if you want to take the next few slides. Yeah, sure. And so yeah, Fedora Chorus is definitely cloud native and container for Kust. That's where we are. And that's where we want to still be in the future.  You will have to run all the software containers. So we have both, we have both FunMan and Moby, the Moby Engine, which is usually known as Docker to run containers. So we support everything. And the OS itself is really made for cluster deployments. So you can either run just one instance of Fedora Chorus by itself that works perfectly. But if you want to spin up like a hundred nodes at the same time and have them join themselves next to a cluster. That's perfectly fine too. And you can do that. And that's where Ignition itself shows its power because you can automatically have every node that boots up, join the cluster and form a big computer by itself.  And if you have a lot of user traffic and you need more power, more CPU and more memory, then you can go again and spin up new nodes that will be provisioned with Ignition. So Fedora Chorus itself, we support a lot of the cloud and cloud providers and a lot of platforms. Okay, we have a list of the most popular ones that we have. But essentially, we are communicating and compatible. So you can run that on almost everything provided that you can give it an engine config. So yeah, mostly supported almost everywhere. Not yet, but we'll see working on it. Yeah, go ahead. So yeah, versioning. We have a strong focus on security and on doing things correctly. The idea behind Fedora Chorus, so we use RPM S3, the mechanism, the way RPM S3 works is like it for your operating system. So it's as if you were going from one version to another of the operating system with RPM S3, just like you would go from one version of your code to the other with Git. So instead, you still have hashes, but you also have version numbers, which are a little bit easier to manage. And yeah, essentially, when you get one specific version of Fedora Chorus, it's one hashes. And then with this hash, you are absolutely sure that what's in this image is the same as everybody else. And you just get the same version as everybody else. So as you cannot go and change everything on the system, because you still want to make sure that all your nodes have the same content, then this means that most of the five system is read only. So slash user mostly is read only. And that's a good, that's a really good thing to add because you don't want things breaking up by inheritance or by mistake. And you want to make sure that all the state of your system is stored in slash bra and that you just keep it there. All the containers, all the data, all everything, everything that you want to have on your Fedora Chorus instance be there. And you still have slash it see if you want some configuration for the software. And finally, the last nail in the security features is Solenox, which is enforcing by default on Fedora Chorus, just like every Fedora distribution. And which really offers a strong protection for isolation for containers on the system. So that's like the strongest isolation that you can get by default. So yeah, so what do we actually have in the in the US shipped with Fedora Chorus? Well, the main thing to remember is that we ship Fedora, we ship Fedora RPMs. So we ship the same content or almost 99% of the same content as Fedora RPMs. So if it works on Fedora, this will work on Fedora Chorus. And if this works in the Fedora Chorus channel, this will work on Fedora Chorus. And so the hardware support is the same as Fedora, as classic Fedora and everything like that. So yeah, it's Fedora. Fedora Chorus is Fedora. And we ship a lot of common tools that you want as an admin. So hardware, some hardware-specific tools and some user management and things like that. The main, the two main container engines. And we only ship the only interpreter that we ship is Bash. And we don't ship anything else. So we don't ship Python, we don't ship Pearl. So that's like a big difference from most other minimal containers. Is there even a compiler installed? There's no compiler installed. So if you want to run a compiler, you need a container image to do that. Everything by containers. Everything by a container. So just commented we don't need busypox either to run a container. Yeah, that's a good point. Yeah. So just real quick, I don't know if either one of you know the story behind it, but used to be in digital ocean, you could go tinker with Fedora Chorus. Now I see that it's gone, but then I went to the Chorus page and I found an image for it. Is that kind of our strategy going forward is just to make images for certain clouds as opposed to like having this deeply nested integrated console kind of deal. If you don't know, that's fine. I can figure out the answer from someone else, like a product manager or somebody. I think it's working progress on digital ocean. It's, we do ship images and you should be able to easily spin them up on digital ocean. And I don't remember exactly the service of or collaboration with them regarding that. I think it's still working progress. I will dig. Maybe for the interface to have like the support for ignition and anything like that. Sure. Yeah, I got it. I will dig detective Conan Kudo and chat. I will actually text message a PM on the Fedora team right now. How about that? Yeah, this should work because Dusty is running OKD on digital oceans and OKD is Fedora course based. So there's like no reason this doesn't work, but yeah, I don't know the specifics. No worries. I will figure it out and I will get an answer. Please continue. Yeah, sure. So that's perfectly on topic because what we have coming next is more cloud platforms. So yeah, more collaborations with more, more cloud providers. We already have a bunch, but we always add in more. And we also trying to improve our state on running. Clément, you're not focusing on. Oh, the joy screen. Should be like. Yeah, you're back. So yeah, we're also working on multi-arch support on better. Because currently we only running on x86, which is like a lot of the workload. But we want to move that forward, especially on 64. I got a box of Raspberry Pi is just waiting to be put together for containers.  Because we it's it's hard to support every single harm sock out there. But if you've got like standard arm, this will work. So I, I don't know about the support for Raspberry Pi, but this is working progress. Nice. Okay, cool. Yeah, I'm not too worried about Raspberry Pi as more and more things come about, right? Like the the arm architectures we should focus on are the server based ones first, obviously, not necessarily for my pleasure, but yes. Yeah, yeah, the server ones are a little bit easier to work on because they put in a start out way. And that's easier to to support. And next, we also have some more FCC sugar, as we call it. So it's more friendly helpers to help you write emission conflicts in a more straightforward way with FCC. So FCC is YAML. That's the one that you should write. And we want to have that being as friendly as possible so that when you write some config, you don't feel like you're you're slow down by the format. Nice. And yeah, we, for a while, we had, we had issues with adding more package more more packages on top, well, not issues, but like limitations. And most of those has been resolved, but we still want to move forward on that. So we federal corrects by itself is immutable, you don't change the host, you don't change the set of packages installed. But if, even if it's not like suggested, you still can do it because our chemistry is capable. He knows how to do that. So you can still have packages on top of that. And it's safe. And, and we, we want to improve on that. So we did a lot of work to make that work and work reliably for days. And we are still working on that to make this more even more reliable and like even more supported. So yeah, documentation two, we want to improve our documentation. We have a good bunch of documentation. If you go on the Federa docs, you can see a Federa correct section and a lot of docs on all to deploy on each platforms and how to work with ignition. And how to write configs, a lot of storage and everything related. And we'll maybe we'll show some some part of it. And finally, some, some, some work on OKD. So OKD, I think it's the next slide. If you could move on, we'll talk about that really soon. So yeah, what's like, okay, we have Federa correct. And there's also real correct. So what's like the difference? What are the relations? So the idea is they share a lot of the tools. We share a lot of the tools that we use to build them and both and and they yeah, they're the same mostly. And the idea is that the difference, the main difference is that well correct is is not to be is not intended as something that you use alone by itself. It's so instead of being based on federal RPMs, it's based on a real RPMs. And it's mostly a component of open chiefs. So you don't run well correct by itself. You run them as part of an opposite cluster. And the difference here is that all the configuration and the updates are managed by the cluster itself. We are operators. So that's basics for open shifts and the relationship with with our course. Federa is is an also by itself. So it's based on for our packages. And even though we share the older toolings, the updates are standalone, you each and everything a node dates by itself. We you can still like other than being part of a cluster and share a big mechanism, but it's not enforced. It's not enforced by the by the system. So yeah, go ahead. So OKD. So OKD is basically open shift on federal echo race. Oh, well, maybe I'll get it. Yeah, it's close to being open shift on federal echo race. So the idea is that you use the same same kind of install it's open shift install and you will get ups and ups and bits of open shift. Directly running on federal echo race and everything there is operator controlled. So it's controlled by cluster. You get almost you get something really similar to what open shift is, but with but based on federal echo rest itself. So the dates are managed the same way and they are cluster managed and the nodes reboot one at a time and one after the other and not everybody at the same time. And the cluster is capable of bringing up machines and automatically if you need more power, more CPU and more memory. So that's basically OKD. We'll have a short demo for if people are interested. So yeah, that's where to get involved. Yeah, yeah, that's where we are. So if you want to go forward with that, if you want if you're interested, you can get federal echo rest on the get federal local websites. There's we have an issue tracker dedicated or dedicated repo and get up to track issues. And of course, we we discuss we also available on the forum. We have a mailing list and RC channel and we'll be talking about federal echo rest. We've been giving a short workshop hands on lab during def cons. At the end of the week, if you want to go over there and meet us there. And yeah, they've got this virtual this year. So everybody can join in. Yeah, it's gonna be cool. Yeah. I'll be doing the dance of the lab. So you'll see me there. Awesome. It's really a good opportunity to have a kind of first experience with federal echo rest and play a bit with it. And the slides are on our speaker deck page. Folks, I just dropped the link in chat. So if you want to pull up the slide and click at the links individually, feel free. Right. Time for some demo. Yeah. Let's go. Go ahead, Kevin. Yeah. So the small demonstration we have today is pretty much showing how to run like a matrix server on the federal echo. It's like host. So we have like this simple and diagram that kind of show you how, how the server and other services are configured. So as the base, you have like federal echo rest that provides more the kernel. So the networking stack. And a container manager. So in that case, we use pod man. And so, pod man is running different services. And all those are configured as system D services. So when the host boots, those system D services will start the pod man pods and the different pod man containers. So we're making use of the pod feature of pod man to have like a share network between each services, so it makes it very easy to configure and very easy for each containers to talk to each other. So they just assume they're on the same, on the same network, you can use like local host. And also like some volumes to store like the data and configuration. So you don't have like to be necessarily a big expert into, into all the matrix server works, but pretty much you have like synapse, which is like the server that implements the matrix protocol database element is the web client. Then you have NGNX as a web server in front of it. And we have like a small NGNX server that you can use to automate the configuration of getting the certificates for HTTPS and having let's send encrypt provide certificate. So we can use HTTPS. I love lesson grip. It's like the most unthought of most needed service ever, right. Yeah, it's easy way to get everybody secure. Thank you, if we really appreciate you. It gives you no excuses to not use HTTPS. Yeah, like my cluster here. I, every time I have to like redo it or whatever because I destroyed it for during a demo or something. Yeah, like that's step one after getting it installed and up and running is get rid of the certificate error. It's just an annoyance that I can get rid of so why not. Yeah. So we talked a lot about FCCT in it's an example of of this email file so you will have a version. For example, how to configure a user and give like some some SSH key. So here it's using some templating by the way there is the link to that repo in the slide. And if you want to have a look, there is a read me where you can, you can follow the instruction and pretty much from that and run your own metric server based on Fedora. Yeah, I just dropped out in the chat here so folks please if you. Yeah, we are kicking the tires. Go ahead. Yeah. Yeah, we just have like a small series that configures C Groups V2 because they are not yet enabled by default in Fedora voice. We just still use C Groups V1. We have like what we are talking about like so for example, creating a pod and starting different services so it's if you're familiar with Ponman, or even like Docker or any container engines is fairly common, you will give a name, like share some variables, some volumes and things like that. So pretty much declare all your services. And those will be provision and configured and run at the first boot of the machine. Like a nice little service that will renew the Redsense script certificates. Yeah, it's checking pretty much every week on Sunday. It's running server to make sure that that our certificate is still valid. So that way you don't wake up one morning and say, Oh, I forgot to date the certificates. And some examples on how you like create directories on your host and how you can copy some configuration file. So for example, all the NGNICs configuration or the configuration for Synapse or Postgres and things like that. So that gives you kind of an idea of what is FCCT and so this is then transpired into JSON. Timote maybe you want to show that part so I'll stop my screen and if you want to share yours. Yeah, I'll do the next one. So here. A terminal, my favorite place. Everything is a simpler feeling. Yeah, so the idea is everything is in the repo. So here it's just a clone of the repo where I've just set some secrets and some variables, some secrets to configure the instance that we are going to create. Because essentially what we have is like this configuration is enough to start an instance by yourself and run it. So you have the main config which is the YAML and we just have a short make file to do some substitutions. So replacing all the secrets value with the one in the config. And if you just go and do that and do that inside my toolbox, that will be it. And you will get essentially is, you will get an ignition config. So that's the last part here. It's a call to FCCT that will pass all the YAML and will give you an ignition config that you can give to a virtual machine. A Fedracor instance. So if I just take a look at what the config, for example, here is like how full you cannot really read it because it's like it's very messy. It's really big and has a lot of compressed data because we have all the configuration inside it. So it's not really readable because what we want to read is this one. It's a YAML here, which is clearly readable with all the data that we want. So yeah, once you have this configuration file, you can go ahead and use your preferred cloud providers, your private cloud providers and spin up a VM, a virtual machine and have it automatically start a Fedracor instance and everything to host a Maastricht server. So yeah, that's what I did just this morning. And if I just go and this is H2 machine, here we go. That's what I have here. So if I just run an Opera Maastricht status here, we can see that I'm running Fedracor S, the latest version, latest table version here. And that's it. Awesome. So what do we have? That's it. What do we have running? Because, well, having a system is good, but like if you can't run anything, that's not great. That's not good, yeah. So here are the containers. So they have been automatically deployed by ignition. The configuration has been written and then the system just booted up and started everything. So I did almost nothing on the system after that. And here we have SNAPs, we have NGNX, Postgre and everything running just like we shared before. So yeah, you can actually try that live. So I've deployed that live on something that is running. So if you go to, I'll just stop checking this screen and share another one. If you go here.  So it's a fully running instance of matrix that is federated with the rest of the ecosystem. So if you already have a matrix account somewhere on another server, you can reach out to me. You can create yourself an account here. Of course, the instance will be destroyed at the end of the day. So don't make that your permanent account. And once you've created that, you can log in. So I'll just log in with mine here that I just created and you can send me a message. And that should work. Yeah, just forget about security. We'll do that later. Here we go. The nice thing when it's that pretty much having this FCCT config or the ignition configuration and knowing that the host is able to be provisioned and to run that, it gives you kind of a very easy way to, to ship software pretty much. You just don't to ship your, your individual containers, but you can start to think about like just releasing the OS with all the service running and everything configured directly as one configuration file. So that's, that's quite powerful. I think for, for services where you have like a lot of moving, moving component. Yes. It's, it's really a high, like something like it takes some bit of effort first because you have to write everything down in the config. But once you've done that, it's really, really high value because this one here, we, we, we did this one a while back to for, for an article and we deployed it. So it took us a while to, to make the config. But this one, I just deployed the machine this morning and it was like five minutes the time the machine boot up and, and you're done. And that's it. And nothing has changed in the config. And, and like, so it's really, really highly viable when you want to boot a lot of instances or when you want to do that frequently. Because if you do the work once and then you reap all the rewards every time you do it and it's, it's really powerful. That's awesome. You can forget, you can forget about it and the box will be updated. You get the latest updates. It's, it's pretty cool. Yeah. So that's another one of the features that, that's important here for, for this, for this deployment is that you will, you know, that this will keep the, the machine properly running and up to date with latest features. Because as we auto update the OS, we also auto updates all the containers on restarts. So if you just leave it running, that's going to be fine because you will just like every two weeks, the house would reboot for days. And then you will get all the latest versions of the containers. And if for whatever reason, something happens and that let's say another version or some version of Postgres does not work anymore, then that's perfectly fine. You just go back to the previous one and you move on with your life while people get to time to fix the bugs. Nice. And that's it. You check again in two weeks. And yeah, if report works, you check again in two weeks and things move on. And that's like the, the power of containers with auto updates and everything plugged in at the same time. So Carlos Santana, who happens to work at IBM is on the channel right now. And he's wondering if there's like a K native thing that you could do with these systems potentially, right? Like an HTTP gateway to be able to start containers based on requests or scale to zero, that kind of thing. Any, any kind of serverless or functions that we can do with for us kind of out of the box, just as long as we have the container, it should work, right? Maybe. I think you could probably, but you would have like to quite a much right the glue that there's the orchestration and spinning up the more VMs if you need anything like that. Yeah, you would. Yeah, like that. There would have to be something on top. Right. Like, yeah, you would want like Kubernetes essentially. So that kind of leads me to my next question is how do you go from F cause. To OKD or vanilla Kubernetes, however you want to describe it, right?  You, you'll have to go straight to OKD. So there's like, there's no really middle ground between Federa Chorus and OKD. Well, you can build your own Kubernetes on top of Federa Chorus. Right. That's fine. You have distribution such as Typhoon, for example, that automates all the bring up of the vanilla Kubernetes cluster on top of Federa Chorus. And that works great. And it's using Terraform. So that's support for God, a lot of support for all the cloud providers. But yeah, so, and on the end of the spectrum, you have, you have OKD, which, which in a sense you don't see Federa Chorus in OKD because it's hidden in the radius. Right. And you don't see it. The cluster and Federa Chorus is just underneath there. I think to me is really the difference is really the scale and the number of VMs you want to deal with. If you have a relatively small shop and you have, I don't know, 20, 30 kinds of VMs and you don't really want to get the complexity that comes with Kubernetes, probably having Federa Chorus is a good idea. I think some, some way to orchestrate that with like a small, small number of nodes. If you start to go into something bigger, it's, you know, Kubernetes is more. Yeah, exactly. Right. Like that's, that's exactly what Kubernetes exists. So if you really need to scale at the big, big numbers, yeah, it's, it's good to go directly to Kubernetes or KDE or OpenShift. If you have like a small infrastructure with like some small services that you kind of want them to be low maintenance and not really care about them. I think it's a very good, very good. I just, I like F cost for tinkering, right? Like I just want to throw a container on something off I go kind of deal and Yeah, I think this is also for me, it has a lot of value or something kind of this DevOps pipeline where Yeah, totally great. Like throw it in your CIC pipeline and just let it rip. Yeah. And instead of thinking about just your application as a container, suddenly you can test all your services, the OS, and you have like this all stack pretty much together. And you can almost, you know, develop your application, integrate everything in Federal Co OS and deploy that directly to to to production and continuous delivery where you run your test and your CI on the OS that will be running in production. Yeah, so someone's asking what's like the minimal like, you know, hardware specs I guess for Right, like what do you need kind of out of the box maybe to just run the OS So the reasonable like low requirements are something like two, two gigs or three gigs depending on how you do the installation. If you do it on live big C, you will have you will need three. If you do it on platforms, you can go with two and that should work. Okay. Of course, that's only if you want to run only really small containers. Because if you want to start like again, really big postgres data base, you will need more memory. Exactly. Yeah, I mean that bare minimum line though is good, you know, like far right like you know you need that two gigs, plus whatever you're running on top of it. So you really can, in a more simplistic way kind of be like, okay, well I know this container is going to be a database and it's going to hold about 16 gigs. So I need, you know, 24 gigs of Ram just to make sure everything works right. That's the basics and on the disk footprint, you need at least five gigs. So let's say six gigs, eight gigs is good. If you want to be conservative and other ways the more the better. Right.  You'll be good. All right. I think that wraps up all the questions. Yes, it is, it is a smaller footprint than CRC, but it is just the OS. Yeah, and just the tools to run containers. It's not the whole kit and caboodle with all the operators and everything. But if you want to get your hands on a developer sandbox for OpenShift, those are available now. And those are ephemeral, I think to the they rotate every two weeks, I think right now. So you can definitely fully kick your tires on OpenShift for free. You can potentially write like just log in with a developer at redhead.com account and off you go. So yeah, thank you, Timothy. Thank you, Clement. This is great. A lot of people, a lot of questions, right? Like that's always a good sign of a good show. So thank you very much for coming on and showing this off and I would love to have more, you know, some related things in the future if you can sometime. How about that? Sounds good. That would be good. Awesome. Challenge. Yeah, great. We'll have to write a new example with almost everything. Yeah, whatever service comes next, right? Like just start adding on to it, right? Like Matrix, IRC. Keep going. Right. Some CI runners or things like that. Yeah, CI or things like that would be interesting. Exactly. A full lab instruction on Fedora Chorus. There you go. Why not? Come on. And then you put way on top of that, you know, everything else. All right. Well, thank you so much. Thank you everybody out there for watching. We will be back on the air here in about an hour with our developer experience office hours. We're going to be talking about auto scenarios, like when to use auto, that kind of thing. So please stay tuned. You know, it's an office hour, so you can bring your questions to feel free. And until then, stay safe out there, folks. Thank y'all. Thanks, guys.