 Please welcome, Sam Chowry, I'm going to talk to you about Hedera Silverloo, I'm particularly excited that Hedera 28 was really neat upgrading, so I hope he's going to do a great sales job. Yeah, I hope so. Yeah. Okay. Am I audible? Like, I will be audible, yeah. So, yeah, so one of the primary thing that I will be talking about in this afternoon is how I migrated to my primary workstation to completely into container-based development workstation, and the primary thing that I would be targeting is the Silverloo project that was recently released. So I'm really excited, right, because so let me tell you a story on how I actually migrated to Silverloo. So I have been working on web-based development for around like five, six years now, and most of my development was around Bay Grant boxes. So for every work that I did, it was usually I used to write Bay Grant boxes because I wanted to segregate all my environments for each and every project. And over time, my laptop was slowly becoming too overloaded with all those Bay Grant boxes in place, and because Hedera, if you know, has a lot of projects in the infrastructure. So to context-switch into a different project, it used to become a lot heavier on the laptop side. So I was looking for something really innovative in that case. So and at that point of time, I also started to look into the containers world, and I also started working with the Federal Courage team. So this gave me a chance to look into the container world. And around the same time, there was a stock by Jessie Prazil on how she has this complete workstation on how she runs every applications on as a Docker container, right, and runs the container. So she gave a talk on a couple of conferences about this. So this gave me a motivation on to look into this container-based development workflow. So I was looking into my options, and then when I was hit with silver-blue. So I'm really excited to give this talk because I want to share on what all things I learned over this last couple of months of migrating to silver-blue. And I'll share a couple of. So my talk would go from how silver-blue works behind the scenes, and how is my work development looks like on a day-to-day life. And finally, I would also like to end this talk a bit like a five minutes before because I wanted to have a discussion around the topic so that we get more feedback because silver-blue is currently in a development stage, so a lot of feature would be coming in in the future releases, so it's better to get the developers' feedback on this. So yeah, so I am Sanjyadri. I work with the federal engineering team, and I'm also working with the federal core OS team currently. I have been a Python developer for around 10 years now. And recently with the federal core working with federal core OS team, I started to work on BOLAN projects as well. And Udoka is my Twitter handle. So options, right now we have a bunch of options out there. So this project was, so around, so the project early started with a project if you have heard known of is federal atomic, so which was, which had two parts to it. One was the atomic workstation and the other was the atomic server project that we had. And so after the core OS acquisition, we migrated the name to silver-blue. And on the other side also we have other projects like container linux, which is gentoo-based, we also have endless OS, which is labian-based. But because Fedora is part of my occupational hazard, so I went ahead with using Fedora silver-blue. So yeah, so I'll start off with introducing Fedora silver-blue now. So yeah, so the main part is it is based out of Fedora. So you have all your RPMs in place, it's RPM based. So anything that you, so the migration, if you do from Fedora, traditional Fedora OS to silver-blue, it won't be a much of a difference. You would see everything as like almost the same. It won't feel like you have migrated towards completely new territory. But there are a few quirks to it also, like princess again on the development side, so you might find some pain points, but it's usually not that much. So again, since I have been using Fedora for like, I started in 2010. So it's been my de facto OS for a couple of years now. And that's why I trust Fedora, I use Fedora-based operating systems in my servers or be it my desktop right now. So yeah, so one of the main things about silver-blue is if you see the traditional Fedora OS, it's like, so if you work on a server, suppose you are working on a server and you usually have Ansible playbooks in place and to maintain that integrity so that when you want to upgrade your servers, you want that to happen in a proper way. You have playbooks in place. So one of the things is you don't want to touch something in production and break it. So when you're doing some live coding, you usually have some testing in place in your staging and then when everything is right, you move your code to production. So why not move all those things to your workstation as well? Because I used to work with my traditional Fedora OS, in that case I used to use, like if I want to install a package, I used to download random packages off the internet, some random table, go through the readme and start copy-pasting all the files into different locations. And what happens after, suppose you hit a step where you can't do anything right after that or the package breaks or it's not working, so you just leave the computer in that state where it has random files which are kind of junk and no use to you. And similarly, if you see from the RPM side when you do a DNF install, it's kind of dangerous because you are changing files which are actually running a system. So it can cause troubles to you and one of the reasons for me, I would say one of the examples I feared upgrade in Fedora was what happens if the power goes off and Bangalore is quite famous for its power outages. So I used to fear like what happens if the power goes off and my DNF upgrade is in place. My system would completely be in a state where I cannot even boot my system. So in that case, those are things had to be thought of in some way or the other. So this is one thing that Silverblue totally addresses it. So you have transactional updates. So just one thing that I wanted to show, this is reported by one of the QA, he's one of the go-to person in the Fedora QA, Adam Williams, and he posted like, do not upgrade your system while running DNF from your desktop. So this is a block that he did, it is excerpt from his block. He as a QA person who is the most experienced probably in the Fedora QA, he is telling people that not to run DNF right now because there are a few issues. So these are the things which can cause trouble in the long run. So one of the things is if you are looking for a more stable system, I would say this is the path we should be going ahead with our system in general. The next thing is immutability and isolation. So as I told you, I used to use vagrant boxes and at the end of the day, the vagrant boxes were something I used because I did not want to touch my whole system. And this goes back to my using virtual ENV in Python. So the reason for virtual ENV is that I do not want to pip install as a root user into my host machine because first thing, the packages can be dangerous. You cannot trust the package completely. And what if there was an issue with a cheese shop in Python that there were a few malicious packages that came into the cheese shop. So you might be installing by mistake some malicious packages that could target your host system. So that's where I started to use virtual ENV and later down the line vagrant boxes where I separately like I have like probably a couple of packages like my editor, a couple of packages like my virtual machine set up and my editor and all those things in place. But other than that, all the projects environment are there in the vagrant boxes. So another beneficial thing for this set up is that you can, so probably it can be like a project a can require a version of a package, which is an older version of that particular dependent package, which is a dependency. And on the other side, you have a package, which is another project which requires a newer version of the dependency. So you cannot install the same package with two different versions. So in that case, you go ahead with using virtual ENV or vagrant boxes. So this is one of the things for isolation as a developer, we always go for isolation. This is very common scenario and this can be totally be handled by a container, which is a more lighter weight solution to this problem. And then comes the immutability part. So this issue was posted a couple of years back, where the author actually by mistake put a space in between the command. So at the end of the day, it was like a RMRF instead of slash user slash lib, it was slash it was completely deleting the USR directory. So this was a big risk. And what if you are on your host machine, if you run this command, you're like, if you see that this actually caught issue to a lot of people and by the emojis that you see that it was like very famous issue at that time. So these are problems usually come in like we are humans, we do mistake. And because of these mistakes, it's usually the host machine is getting affected. So in silver blue, we have the only the var and at C directory is only writable and all the other system is kind of in the read only mode. So there's only one thing that the option that is left to you is using containers. So the pro so silver blue bias nature promotes you to use more of container based development. So you can be using each and every application within the within an app container framework be it your browser be it your be it your maybe your servers and etc. So you are it forces you to kind of use the container environment. So this is one of now going into the internals of the project. The project heavily uses our PMO history, which is kind of the core of the syllable project and it's the same for the federal corvus also. And what is our PMO history? So our PMO history is built around the art. So if you go by how the project is built is basically it uses a lips libo history project, which kind of what it does to your system is that it makes your complete system at as a gate version system. So you basically have a couple of versions to your system. And I'll just give you a small demo around it. So is this is this visible? Yeah. So if you see like this is if you see this dot, this is the current system that is running and there is a hash to it. So because this is a content addressable of just so what it does is that it is for every deployment that you do it downloads the RPM, creates the image out of it, hashes all the files, sees if the files are reduplicated or not. In that case, it intelligently solves the issue of not downloading the same files again and again and does and also via hardling. It does not. It's kind of reduplicates the file. So basically you have this hash in place. And this is the current system I am in. And this is the older system I am in. So when you do a RPM OS tree upgrade, so what happens is that it does not affect your current system and in place it creates a new deployment. This is like you would see in that case three deployment. And then when you do a reboot of the system, you would finally migrate into the newer OS. And if the new OS breaks, you also you usually have the option to migrate into the older one. So and Silver Blue comes with a base image OS. And on top of that, if you see, these are the RPMs that are installed. So it works as a layer. So if you know about the container layer system, it keeps on layering the new RPMs that are installed. So this gives you a good idea on which are the packages are installed in a system. You can always overwrite them or remove them. And that would make your system kind of atomic in nature. So if you want to, so if two machines have the same package installed, you probably would get the same box if you have. And you can probably go ahead and file those issues. And another thing is, if you see, these are the local packages. So these are the packages that I did not install for. These are the packages I did not install from directly from the Federal repo, rather than I installed it locally. So this gives you a good overview on how the system works. So moving ahead. So how does this help the developer? As a developer, if I'm pitching Silver Blue to you, so these are the things that you would be finding useful. This mostly comes with all the container engines. There's Docker. There's Portman. I personally use Portman for the non-rootless containers. And also Portman is very light because it runs Daemonless. So in Docker, you have the Daemon running continuously. So I personally use Portman for all my containers. And then you have Builder. I have not used it much, but I have heard a lot from the people. It basically creates OCI images for you. And the next thing is Scopeo. So Scopeo is another project built by Red Hat to inspect and manage your images. So these all projects come along with the Silver Blue project. Another concept that has been introduced with Silver Blue is called as Pet Containers. So Pet Containers are basically like, I probably would have containers for different projects. But what if I need a container which does a lot of stuff for me? It can be a regular container for me. Like in virtual NB, I used to have a temp virtual NB where I used to just install random packages in it or to test things in it. So Pet Containers is very well managed by this project called Toolbox. It's still in a heavy development stage. So a lot of things would be coming in the future. The next thing is FlatFax. So if you have heard of FlatFax, basically a lot of apps are getting migrated into FlatFax. And so you have the FlatFax from where you can install the application via FlatFax. And probably for me, most of the PDF reader or maybe the Spotify client all are running from my laptop is running via FlatFax. And it has a vast, the Flat Hub actually contains a vast app. It has a lot of application in there to install. And the future plans for it, like we are getting more R&D, monastery support and FlatFax into the GNOME software. So you can directly install it via the GNOME software center. And then we would be doing a federal toolbox release with more development in place. And right now FlatFax are not installed directly on the Silverblue. So probably down the line when we are doing the final release, you would be finding FlatFax as a part of the release itself. And we are looking for faster downloads so that the downloads that happens. And so the R&D, monastery downloads that happened was Silverblue. We are trying to make it more optimized and faster. Right now it kind of takes more time than DNS. But we are looking for a more faster download in that case. And in a distant future plan, we would be having more toolbox integration. Basically, you would, so if you are basically, if you are on your terminal, so there would be kind of a visual difference on if you are inside a container or not, or are you on a host or not. So those are all things we would be working on in the future releases. There would be, we would be targeting more container available to the community. It's like probably make things around it and have like TensorFlow container or like maybe image processing containers in place so that it becomes easier for people to use Silverblue on a daily basis rather than writing their Dockerfiles or creating their containers from scratch. And right now like using Chrome and virtual box are kind of difficult to use because of the display users. So in that case, we would be trying to have more difficult containers for the community done by the people who are building Silverblue itself. So it's basically toward the end, we are trying to have a more better UX and UI for the general public. And we are trying to make like Silverblue as the de facto workstation for Fedora. So now what? So going forward, how can you contact us? So we have a discord, sorry, I forgot the name, it's not discord. Anyway, so we have discussion.fedorproject.org where you can post your comments in there. We have silverblue.fedorproject.org where we usually have questions in place. So if you're new to Silverblue, you can just go in there, ask for questions. Since everybody is starting with Silverblue, there are quite common questions. Me starting as a newbie, I found a couple of questions there itself in the community platform. Or you can directly go to Silverblue on FreeNode IRC, join them and you can probably ask a question in there itself. So questions, yeah, yeah. So you can, so the question is like, can the Silverblue gives you something from the OS level to launch your application or you have to do it manually, right? So we don't have we right now. So what I do is I have kind of make files in place. So what I do is using those make files, I manage my container is basically running the portment container. This is probably in the future, we can have those GUI support so that even through GUI, you're actually running the container. That could be a better approach. But right now it's just plain, I use myself a lot of make files in that case and run those, manage those portment containers to attach or start or run those containers. Yeah, yeah. Yeah, flatback would like, you can search it through your Chrome search bar and install them. You can start those applications. So that would be simple. Yes. So we are probably deprecating those. So basically we are deprecating, you won't have those alpha beta channels like N4OS. Yeah, but in Silverblue, it's you can just you have the image. So we usually in federal have composers, which happens on a daily basis. And how federal boxes usually have this raw height or the stable one. So you can usually do RP Moisture upgrade and whatever packages are there, which have been there in the upgrade in that particular OS. In that day, probably it would just download it and relay it over on top of it. So yeah, but we don't have those different channels. And after this, we'll be talking on federal core OS on how we are migrating from container Linux to the federal core OS project in general. Any more questions? I don't think so. Is there is any limit on layer packages, but usually it's recommended to use more of containers rather than layer packages. That's what I have read from the, got it from the discussions and the blogs that I've read. So yeah, so if you have questions, you can probably drop me an email or ping me on Twitter. So that's the end of the talk. Hopefully I did a good sales pitch. Yeah, thank you.