 So I put like this yesterday to the slides because I like what Matthew Miller said about Silverbrew that Silverbrew basically is a federal system for living in the container world. I think that it really makes the point because they are like maybe we could replace it even with that toy story picture if I contain us everywhere. So that's like how we can like describe a Silverbrew. Some really basic stuff about Silverbrew. So it's basically a next-generation desktop operating system. It's like it's using some fundamental technologies like OS3 and RPMOS3 that are that were basically developed by the CoreOS guys. We are sharing another like technologies with them and we are together if you put these like technologies together and it will actually make the so let me rephrase it again. So we are sharing like a lot of technologies with CoreOS team like OS3 and RPMOS3 and then even in the toolbox. What's like typical for this kind of stuff is that they are so OS3 as you probably know is basically Git-like system for file systems and like to deploying images, the operating system images and so on. So some parts of this file system are mounted as a read only. That's like it has some pros and some cons that we will actually talk about later. And another great thing about that is it does atomic updates. So it's like necessary to resound to the new deployment when you actually doing the update and so on. So the main benefits of Silverbrew are at least enough point of view the robustness. Robustness of this system is basically done by these things that I mentioned over there. It's like atomic updates. So you basically avoid the life updates that you are probably used to from the regular Federal Avenue update the system by running DNF. But the thing is that it's not a great idea to update on life system because it could be like several, there could be like several problems. And if I remember from the past there was I think NOM was crashing at some point and it was suggested that people should like download update the update the that particular update like running in T-Max if they didn't want to like the crash the whole system. And also there was like Firefox was misbehaving because some library that it used was like updating why it was why the Firefox was running and then the Firefox was misbehaving. Another part of the robustness was the minimal base OS. Actually there's the minimal operating that the base operation system that it's just so it should be like minimal to actually decrease decrease the the problems that could arise from like basically adding more and more packages into that. And it could be like basically by proof from the problems with updates when there are some conflicts and so on. The minimal base OS we are looking forward actually to the work that is done by Adam Shamanic and others the minimization effort because it will allow us to decrease the proper decrease size of the base OS even more and also do. So the minimal base OS it's really the base operating system. It's like currently it's still not decoupled completely from the applications are not completely decoupled from it but in the future everything will basically be in flat packs and in containers so we should really have like the the base operating system should be really minimal and just like more robust. Another part of the robustness are read only parts of the system that basically slash user is mounted as a read only. So that means I don't know if you are if you have the same experiences as me but when I first got to the Linux I many times like completely discern my system but removing some random library and so on but this at this time if there will be something like server brew it could help me like a few it would save me like few maybe not a few many more hours than fixing reinstalling systems and trying to find what's wrong and the another part of the robustness is the ability to rollback that means that if you find that something is broken in your currently running image then you can easily return to the previous one also another benefit is security that's basically combination of the previous parts that that's read only parts of the system and also the minimum base based on us because we are like decreasing we are shrinking the basically attack surface by removing quite a few applications from from the from the main OS also it's there is a known deployment we were talking about with some IT shops that are deploying some operating system across their company and they said that they would they would like to have something like server brew because when they are handling the hardware over to to their employees they give them in some state but as time comes and people are adding removing sound adding can remove stuff from the from distribution then it gets into real estate so they when they actually try to produce some scripts or anything like that they expect that that the system is in a well known state but usually it's not and then they are just fixing the problems on like on each employees system alone so that will be really helpful for them because then they could like predicting what state or how do how the system will like and also this like the example so the base operating system is the most important part into a degree it doesn't matter if a container breaks or an application doesn't run but it's totally unacceptable to not have the main operating system working so we have to have the the main operating operating system working to actually because if you are let me rephrase it so I'm I do have a second laptop with an media and as there was the kernel 5.2 release the and we are binary drivers are not compatible if we did kernel and as I running server on that when I was trying to upgrade then basically the kernel modules for Nvidia are compiled during the update and so actually the update doesn't basically is not completed because there are some compilation errors but I'm I don't have that particular update like installed so it's not like in the old days when I would not just restart and the AK mod and so on we'll try to compile the module while booting the device and that I would be like there with the broken system so that this will be like so when could like several reprise the current federal workstation yeah so we're currently we don't really have any any approved plan that silver blue would replace federal workstation but it's different differently something that we are considering it may happen in the future but only if if really it's it's a acceptable replacement for federal workstation and certain criteria we are gonna talk about are met so this is you could hear I mean the the con in terms of the software content silver blue is not very different from the standard federal but the biggest difference is in is in software delivery so it's not like the traditional way we install packages and they basically install stuff into the system itself the system the system is basically immutable and the the standard way how to install software into silver blue is through containers and it's either could it could be podman for clear applications for command line applications and it's flatback for chemical applications that's the that's the preferred way it helps us in in a lot of ways one of the great things is that you basically can decouple the applications from the base operating system they can have different life cycles so the applications can you know update and obey themselves no matter you know no they're lying on the underlying operating system so we can you can get sort of like to speed it well where the system could be stable with some lifetime the applications get updated as as they as they needed or they are released then not yet yeah so much is going to talk about toolbox it's actually one thing we we consider for the to have a nice you graphically why for that but we currently don't it's a common line base right now well there is there's also another way and that's that's package layering basically rp movestry allows you to to install rp m packages from that position is directly into the base os image so it basically out there's the the os image that is delivered by federal and allows you to in have changes by rp m packages in the base of s well it has some it has some limitations first it goes against the idea of immutable system so one one of the benefits of silver blue is that we as a federal we can test and deliver the base of s to you and and and we know that's gonna stay that way but once you start changing it by rp m os stay it's not the case anymore and another another thing also is that it's it's a nice way it should definitely be something like the last resort when you really need some package that or something that can't really be done through the preferred ways then then you should do it like for example you need a driver for a painter that is only available as rp m and needs to be in the base of s then you install that one driver but once you go into dozens of packages layered over the standard base of s then first like you can run into unexpected issues because that's not just set up be we test it and deliver and second once you for example you want to a base to another release of federal then it it may not just go through the database because of I don't dependency issues etc so this this is this is still there it's probably be a solution for things that we won't be able to solve differently but one of the goals we have is to minimize the cases or that would be in which it would be the only way for users so once we once we are good enough that you know package layering is definitely just the last resort for a few cases then that would be the goal so I mentioned flat pegs is is anyone here at least a bit familiar with with flat peg as a as an installation format so it yeah so it's basic is it basically a format that works across distributions pretty minimal dependencies so you can you can create one in installation could be even a file that can then be installed on different distributions no matter you know what what components they have etc it's basically all contained in a basically a container or sandbox so currently there is like the main source of flat pegs was flat up which is pretty much an upstream project quite associated with the with GNOME but also KD is involved and another like companies like endless for example they it's on flat have flat pegs are basically built from source mostly I mean any if it's a proprietary application it's just it's just like packages some some binary or some flat pegs work even with with packages that it basically if there's for example an official the package it's just pretty much unpacks it and installs it in innocent box so it's not always a source to flat peg but mostly and we also started working on a federal repository of flat pegs and the the fundamental difference is that they are built from from rpms and only only from rpms so basically what you get is something that is basically verified by by the federal project so you you are not going to end up with some arbitrary stuff that was added there by a maintainer for example in a flat have so it's it's it's something that we can ship by default in in silver blue because it meets also the order legal requirements the requirements etc and that's one of our next criteria basically that if you want to go out seriously with silver blue then we need to have an offering of those applications by federal not really completely on flat have on the other hand yeah so this is the this is currently the situation so flat have has been here for much longer I don't know three years maybe it has already accumulated 600 applications while Fedora I've been working for on that for last months think the the building itself was introduced at the last floor but it took a while until it was usable so we currently have 50 applications which is which is not bad and we are progressing as I mentioned also the Fedora ones are face-off to wear so they basically are have the same license and illegal requirements as rpms packages in federal since they are built from them yeah at flat have you can get software with different licenses open source proprietary etc here Fedora the flat pegs are maintained by Fedora community while at flat have it's maintained by like either software vendors who are behind the applications themselves or community volunteers for example the the original author is not interested in maintaining for the flat peg they are community volunteers who are doing it for users also a big difference is is that flat have flat pegs are using always stay so the same technology we use for the the base OS in silver blue while Fedora is more aligned with modules and containers in in Fedora so we use OCI so if you install the application it behaves the same way it's just delivered and stored in the in the register your depository as OCI compatible archives instead of having an always stay repository yeah we can't we currently have still some problems with Fedora flat pegs so for people who want to build them out out of rpms packages there is there is still a lot of manual work involved so there is currently no automation so for example let's say your your flat peg is built out of 10 rpms packages and in the ideal world and that's the ultimate goal is that if there is any change in one of those 10 packages then like a rebuild of that flat peg gets like take care automatically and you don't even have to do anything about that it doesn't work that way currently you have to you have to take care of the build yourself and also right now as the flat peg maintainer you don't even get a notification about the changes unless you set up your own filters in Fedora message or something like that so it's currently it's it's it's not that easy to to maintain the flat peg so this that's definitely an error to work on currently we also don't have any policy set for long-term support and maintenance it to have a flat peg you basically have to ask for another repository where you host the Dremel configuration files so we don't really have to be even like a package maintainer of that application so if there is for example Firefox in federal repositories you can package Firefox as a flat peg and you don't have to be maintainer of those rpms packages and currently we don't really have set any policy or boundaries of responsibilities between package maintainers and flat peg maintainers and the flat peg maintainers ultimately rely on rpm maintainers because sometimes you really need you rely on spec files on that build sometimes it's I think it's also somewhere mentioned that sometimes the spec files have to be adapted or fixed and the thing is that a flat peg basically is not doing any sort of overlaying because you've got that runtime this the application is using as a running environment and then you've got the application and its files on the top of that and when flat peg was created there was no reliable overlaying technology that would be present across all distributions so basically what the founders decided was that basically the runtime would be in slash user and the app content would be in slash app which helped back then but it caused a big problem for us now because basically now we can't use the rpm packages as they are already built but we have to rebuild them with this with this path and you wouldn't you wouldn't guess into how many issues we or problems in spec files we are like hard-coded paths etc and it's something unless it gets fixed in spec files we are stuck on that so really the flat peg maintainers they lie on the quality of rpm packages and their maintainers a lot so that definitely needs to be some some policy and and boundaries of responsibilities on that done also we have a we have we are planning to set some goal you know how many flat pegs we'd like to have available as federal package federal applications as flat pegs so currently there are over 1000 desktop applications or more precisely rpm packages with desktop files in federal repositories and to go out seriously with silver blue we would like to have at least 30% of flat pegs so like around 300 and we are currently at 50 so it's like we have to multiply the current offering all there are still what we currently don't support our delta updates that's the that's caused by using the basically the OCI format that doesn't support it if we would have sticked with OST and we would be fine because OST supports those updates for a long time that's something we would have to definitely solve because currently like you've got Fedora runtime which is 300 500 megabytes and basically if there is a single component changed then the users would have to download 350 megabytes and you can imagine how often components change just in the base image of Fedora so you would definitely have something like delta updates for that currently we also we haven't solved the localization in flat pegs so you get it them in English only but that's definitely something we would have to solve for so to meet the criteria what's also quite annoying for people who want to build the flat pegs is that if you want to build it locally there is no caching which is particularly annoying if you build a big application like for example Felipa is building no bonuses that basically includes all the actualization stack and how long does it build like three hours imagine like you it builds for for example three hours and it fails because of some error you fix that error and you let it build again and you wait another three hours to actually find out if they if it fix the issue or not so this is this is something we have to work on as well so yeah yeah that's something we don't have mentioned on the slide yeah one of the goals like pretty close ones is to have flat pegs and on times pre-installed on on silver blue so currently the basic set of applications is part of the base image we'd like to have all applications besides like really system ones like system monitor etc as flat pegs so Firefox is currently on the base image it should be moved to flat peg so we are working on or actually the Anaconda team is working on having them pre-installed downtime and the base set of applications and now too much is gonna talk about toolbox yeah so flat pegs are meant to be for the graphic applications and toolbox is actually maybe I'd say not something about toolbox what is it about it's like it's used to moving the development from the base operations system how it used to be away from the main operating system to actually into containers that way how it's done that we are actually mount the passing basically shell script around the portman and what we are doing in the shell script that we are passing various various variables in into into the container and so on so even the graphic applications works inside inside the toolbox actually is also it's a easy way to get the traditional fed around the silver blue so if you spawn the toolbox container and you have the regular federal over there so you have DNF and everything and you can play there play there and without like any consequences on on your main operating system so we really want to get people use the toolbox and so on adopt the workflow to actually have the separate toolbox pair projects let me say like Python development C development this kind of stuff and also we want to have like special toolboxes for for software that's actually hard to configure setup and so on so I was working with team in inside red hat to actually have the TensorFlow container or TensorFlow toolbox ready because like TensorFlow is not that easy to easy to configure so as I already said toolboxes I shall wrap around the program project that's nice but during the last half a year we already had some programs with portman and its regressions it was basically it was not a week when something didn't didn't broke so we are thinking about rewriting it in go why go because portman is written in go and we could like easily incorporate the unit test into portman that will actually test our use cases also we are thinking uh I think about uh some like our integration to the OS as Linden asked about the some application that could like at least available like toolboxes and terminals and so on so we do we want to have some application that will showcase showcase what's available and what actually uh users can consume and also we are we will like try to modify the non-terminal regimen as already like done the preparations for that to actually like really distinguish uh in non-terminal in what toolbox you are and so on so probably like some differentiate by colors and so on so it's like uh easily easily so it won't happen that you will uh by accident write some uh command in in a different toolbox or or in the host when you need to run it in a completely different place so another part of this is that we really want to uh make it easy to actually work with the with the system operations like to make it easier for the regular user to update and so on the the main operating system so we want to like improve non-suffer currently it only supports the uh the update which basically means rpmsg upgrade uh we want to actually have the uh system upgrade there as well that means actually like rebasing to the another tree or another branch uh also we want to have like uh support for rollbacks so people if they will find there's something wrong with the currently deployed image they could like easily rollback to the previous one that was uh working flawlessly and also the persistent rollbacks that maybe Yezhi will talk something about I mean generally this this is all uh possible well through rpm or stay uh in in command line but we like to improve the the user experience by uh supporting it in graphical interface in GNOME software yeah the the persistent rollbacks it's basically uh if you if you are based for example from federal 29 to federal 30 uh you find out there is something not working for you uh silver blue easily allows you to go back to federal 29 you just debut to choose in guarantee the second and which is the the the old image the thing is that you if you boot through the the old image rpm or always stay is still pointed to uh federal 30 uh three or branch so basically uh you if you want to switch permanently to federal 29 and wait for example a month or two until your issue is fixed then you have to change uh that uh range as well and currently you can only do it through uh command line uh or command uh by your rpm or stay also maybe the last flatback rollbacks that's something you can do it also for uh for applications so uh yeah not only the os if something basing the or as you can go back but we'd like to support that also or make it expose it to users also for applications because flatback allows it for applications as well so you for example update uh the liberal phase six point three was released today so you update to that you find out that something you know there was some variation in calc and some of your spreadsheets just doesn't work with that you can if you implement this you can then easily go to gnome software and you click a button return to a previous version and it gives you the previous snapshot of the application so that would be uh really good as well okay the another thing that we are thinking about like changing a little bit is that are we operating too often and as you can see that based on the feedback that we are getting yes they are like nearly every day there's an update go go in people are like constantly like getting notified by gnome software or anything that they should they should update and so on so we want to actually like change the stuff there to actually slow down the update sick update cycle to uh just two or three weeks or even maybe a little bit longer but that's like to be decided uh it needs to like we have to cooperate with federal crew about their opinion on that because what we want to do in that time is to like we really want to like properly test the update as a as a unit so it's not like like separate updates that can influence each other but we want to see like the bigger picture how it looks when you actually test the update as a whole it could be like done by uh manually by the early adopters and so on or automatically but that's to be decided by the federal qa so people like should like easily obtain for for the regular cadence at the cost that they will actually like update daily if they want to also uh what about the sec security uh updates so definitely the critical vulnerabilities will be pushed like asynchronously because these are more important and maybe we will see if whether the same should be done for the import important like vulnerabilities but that's needs to be like cooperated with the with the security team uh basically as I mentioned at the beginning there are uh some cases where uh it's not really you can't really uh solve them through containers because we need to work with the with the base image and those are probably uh the cases where we will have to use the rpm or layering and yeah one of the the cases is is drivers for example it could be even a third party software that is not available as uh flat packs so currently we use rpm uh layering for google chrome uh for example with with the drivers it's also uh i mean we one example of of taking problems we run into is that uh you know you probably know hp lip right that's the the tool for hp painters and uh so you can you can set up uh the hp painters through that and what some of the painters require uh like a proprietary plugin that have to be that has to be downloaded from the hp service and this plugin is installed into a path that is set only in silver blue in in slash user something so we were like hey hp lip is open source we can just patch it so that it downloads it into var or something uh what the case is that when we when we uh actually investigated that we found out that uh it doesn't download the the plugin uh directly it downloads a binary from hp servers and that binary does the download so you cannot really you cannot really patch it uh so looks like it's a it's a case until we of course contacted the hp uh developers if they could fix it for us but it's definitely something we just kind of go around that so that's that's a case where we will preferably use rpm layering uh there also the debugging experience maybe talk about it these are basically uh from my experience so imagine a situation that uh something no you don't even have to imagine it's like uh day to day life that's some application or anything crashes and it's it's the part of the os so how you can get like the useful vector race or anything like that so if uh with server rule it's really hard because you what you could do is like to get with rpm to get uh it's like the version of the insta package and to go to the koji and download the debugging for packages and so on it's like that's a horrible experience so what actually os3 allows you to do is like to unlock the system and have like made a regular regular uh rightable system from there and i'm personally losing uh some scripts that actually i'm downloading and installing the micro dnf and with micro dnf i'm installing regular dnf to actually have the debug the bug info plugin and at that point i'm really it's easy to like get obtain the debugging for packages and then provide the backtracks to uh to to the developer or anything like that but really the process really can be in that way and has to be like simplified and so on the problem is that we could maybe reuse uh abrt for that but it doesn't play well with with silver bullet and we really have to like talk with uh the abrt team to actually improve that situation and the last point over there is like dual boot use experience so what what you could easily try the silver blue on your not easily you can try silver blue on your regular federal workstation by actually deploying the os3 image into your root partition into the os3 directory and then just upgrading grab and just booting from over this directory the problem is that the uh i think if you are using grab not ufi uh was it like that uh you have to manually update the configuration after like any update of the kernel i think so there are really some big problems and we should really make this like to work flawlessly because if if we fix fix this we could get like a lot of like early adopters of silver blue and and new users that's actually all the team on their laboratories is supposed to work on that and hopefully we should get something really soon here are some yeah documentation issue tracker uh we we are planning the silver blue project in in teams dot federal project so you can if you want to see what we are working on and the progress etc you can you can take a look there even if for example you want to want to help and contribute yeah but actually once as we are working currently on the roadmap i suspect that the the taiga instance over there will the entities over there will actually change a lot to actually align with align with the video map yeah okay so that brings us to questions questions anyone appreciate your question so how many people try silver blue in this room oh nice wow do you like it nice and from those who didn't try it yet do you think that fixing the the like the doula boot experience could like convince you to try it no one okay so yeah all right my my name i actually set a list that are already to some of you guys but um my big problem is um plugins in uh flat-back applications um a lot of the time they don't work right you have to like you know figure out how you can install it somehow inside the container so you want to use something like vs code it's very very okay that's that's that's not a plugin that is packaged in repositories right okay there's still a bunch of like hurdles um about using it you know they are not probably applicable to like an office worker right yeah i mean with vs code for example one of the the issues we also have to fix is basically that uh vs code should should nearly work with uh the components that are either in the the flat-back on time or in the host but we like to find a way like for example you can hook up your development portman container for example with that application in in flat-back so the other big problem i had is um you know there's lots of software that's not there yet right um and you know i think toolbox starts to get down this path but i think encouraging a mechanism where you can get booby tools that hadn't been put in the flat-back yet so the big one i ran into and this was a while ago but it was meld um you know i wanted to get meld couldn't bear out of a way to get it without having to reboot and i was like well i'm not you know i'm not gonna reboot every time i need this software so i think in some combination of toolbox and like being able to launch doings from toolbox like solo i think chunked that problem of thing you know it's like yeah i love to adopt it but i still can't really break my workflow being an early adopter right you mean like pro pro pro but you have to have to execute like execute the command in in the terminals i mean i wonder if there would be any way to explore to the desktop files right i think i think the point being like and that along with like i think there should also be a alias on d and f for example it's over the moon it kind of says hey this doesn't work here this is what you should do instead right it's like i think in the earlier doctor phase right there's a bunch of stuff we could do that kind of says hey you're doing this wrong but until we can do it right you know this is the workaround right these this is how you approach solving this so you can get over that barrier to entry because the goal right is to get as many like developer type using it if possible it doesn't have to be perfect right we can just tell them that they're doing something shrewy and then fix it over time okay any other question comment just to second the opinion it's same for me what is keeping me back from using it on a basis like the main environment is not the driver it's not part of software it's not read only slash user it's a perfect application or one of them and even if there are they are often like not working as well as the rpv version so that's in my eyes this is the major issue it relates that to another example is um so i play a stupid uh game it's kind of a like a grapple version of that hack called shattered fickle dungeon somebody wrote a flat hack for it i was like all right um so i was playing around with it it's like many versions old um and so i went and updated the fly bag um however i can't there's no automation there at all to actually distribute a version of the build um even though it passed like there's no automated tasks and all that stuff but not going to still wait it's already been at least a week for somebody to go uh actually act you know emerge that that request it you know that's that's flat that's flat hub or oh yeah okay i mean i'm working right now right i think there's probably somebody i could pass up to go actually fix this but that seems like a fairer to ensure it doesn't need to be there you know what's about a different physicality model uh i mean uh i i don't think we want to support the use case that you install silver blue with gnom and then you can besides that you install xfc kd etc i guess this is something that i mean the whole i mean the immutable system as a concept uh doesn't really work when you want to do huge changes to the base of s it's really for users who want to just use the base of s it works for them and they do everything on the top of it once you want to build your own kernel install different desktop environments and have xfc on monday and kd on tuesday etc then then traditional federal will serve you much better but it doesn't mean that there can't be silver blue without like with other desktop environment i think there is no there's kd and xfc spin all right driven by community yeah yeah so basically simply like kd plasma spin and xfc spin no one no one really holds the the community members from building them but yeah it would be kd spin just uh the scenario where you have you know you install various or multiple desktop environments side by side by you can theoretically do it through the over uh layering but that's yeah not good yeah you need you need direct access to it really makes sense to to run it in the same new space that's totally based on us yes if you don't have working demos you're we started looking at trying to do some models uh try to help how to break up you know as its own model or it's still really hard i think i think the i think the goal actually is correct in that um we would like to separate out the desktop environment you know and all its friends from other parts of the operating system but i'm not sure that flat pack is the answer to that even it just doesn't make sense to me to run it in a container in a then then you run into lots of problems right you know the the base desktop components actually contain in a container and they actually have to interact with other components in the base of us frequently you see into how many issues we are with sandboxing desktop applications like sandboxing desktop based desktop components that would be like hell of fixing and i really liked what christian said yesterday on this talk we will actually do the the research and so on fix the like do the hard work and so on and at that point community could just take our work and replace the non-packages with anything what they want but i expect that they will need to add up like kd stuff and so on probably no no but i expect there will be some changing that needs to be done to fix this themselves okay any other question probably a last one since we are so if nothing so thank you for your attention attention